Add support for cherry picking on pull requests

Issue #7842 open
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 (74)

  1. Erik van Zijst

    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

    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. Tim Razik

    +1 when you have hundreds of developers working in a flow, merging hot fixes to master and develop becomes problematic. Cherry Picking a commit would be nice so that I don't have to manually double maintain code so often.

  10. Anonymous

    +1 at the commit level. Four years after the issue was raised, how is this still not implemented?

  11. Tim Razik

    I have been using bitbucket more and more and see some odd behavior, such as when merging a pull request, it sometimes does not move the HEAD to the latest file. I can see why adding cherry picking could be trouble. For people waiting for this feature, we have been using rebase to bypass specific commits. It is far from ideal. It would be awesome if we could resolve simple white space conflicts and cherry pick directly from bit bucket, but I can see why it might be complicated.

  12. Anonymous

    @Tim Razik I've noticed recently that sometimes commits that were included in one PR, approved and merged into the target branch, show up again in the next PR that I create - is that what you are referring to when mentioning HEAD not being updated to the latest file?

  13. Dave Bignotti

    +1 for a while now. With all the demand going back almost 4 years now, please Atlassian, at least give your users an idea of where we stand on the possibility of getting this feature at the commit level.

  14. Christian S

    +1 for having the option on commit level

    I'm also interested in not only having the option to cherry pick commits when accepting/merging the Pull Request, but also when creating it.

    And I cannot believe that this is open for FIVE years now without anything being done obviously...

  15. David Freeman

    We use gitflow quite a bit, but it means that when we merge from develop to master, we tend to pull in everything. This doesn't work, especially when we have shared repositories for shared assets.

    The ability to cherry pick commits when creating a PR directly in the web UI would be a very nice benefit for us. Especially for operations team that has multiple shared repos, but themselves are not expert git users.

  16. Log in to comment