1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues

Issues

Issue #7842 open

Add support for cherry picking on pull requests (BB-9006)

Moises Henriquez
created an issue

When someone issues a Pull Request, I'd like to have an option to cherry pick which files to accept. If I spot something I dont like on the diffs, I'd like an option to reject that particular file without having to reject the entire pull request.

Comments (46)

  1. Erik van Zijst staff

    How do you see this working? Would you expect to be able to still merge the PR and only merge those selected files? Or do you merely want a visual element on the page to communicate to the author that one or more files need more work?

  2. Erik van Zijst staff

    But that might mean that Bitbucket needs to create a new commit on the source (or intermediary) branch first, where some of the files are reverted. Otherwise the merge isn't actually a merge.

    Cherry-picking is normally used to apply (all) changes from a specific commit onto another commit and does not work on a per-file level.

    To be honest, I'm not sure how feasible and practical this is, but I'll raise an internal issue so that it can be discussed.

  3. Dave Van den Eynde

    I landed here after a google search, and I must say I'm also interested in the ability to create a pull request based on one or more specific commits via bitbucket-side cherry-picking.

  4. Bill Johnson

    I would offer that this functionality shouldn't cherry-pick at the file level but at the commit level. A pull request is a collection of commits and if a commit is declined, it is removed from the merge once the pull request is approved.

  5. Maximiliano Bregante

    I need some help here... I'm voting +1 at commit level, but please read and clarify my thoughts if I'm wrong...

    I would like to apply changes from a commit to the target branch, without having to apply "all the history" from the source branch (where my commit comes from). What happens is: I have a RC branch that at some point gets "somewhat different" from my master... so when a bug is detected, you go and fix it on a bug-fixing-branch from the RC branch... then what I'm expecting to do is 2 Pull Request:

    • Pull Request to integrate the fix to RC branch
    • Pull Request to integrate the fix to master branch.

    But then when you want to apply that fix to the master branch, I get many files to be merged back from the bug-fixing-branch to master, even if my fix (the commit) only has 1 file/line.

    What I end doing is creating a new bug-fixing-branch-master from master, and manually apply the changes there, and then issue a new Pull Request to reintegrate to master. Totally bad as far as I can see.

    How should I work in scenarios like these? I'm not a git expert, I just got the basics, but it seems to me that I must cherry pick my commit from my bug-fixing-branch (branched from RC) and apply that to master?

  6. Dave Van den Eynde

    That is exactly what cherry picking does: apply the same changes as another commit on your current branch without including all of the other history. It's what you've been doing manually, but in an automated fashion.

  7. Michael Hardin

    Very useful feature and I have a slightly different use case.

    I have a merge with commits A, B, C, and D. C is a merge message and D is the child commit of C. I don't need C or D because it's from a branch that I have already merged so I want to cherry-pick A and B. I would like for bitbucket to recognize that I have already merged in C and D and that in cherry-picking A and B all commits from the pull request have been merged in so it can be marked as merged.

  8. Madhur Bhaiya

    +1 for cherry picking at commit level. Very much required. It is essentially needed as administrator to a particular repository are few, and it gets very cumbersome when they have to cherry pick manually, because of numerous specific pull requests by developers only a daily basis.

  9. Log in to comment