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 (20)

  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. Lukas Meindl

    Doing this on a per-file level is not feasible. On a per-commit level however this should be both doable and useful. +1 at commit level -1 at file level

  6. 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?

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

  8. Log in to comment