Desktop: Feature Request: Cherry-Picking commits from another branch

[kiuru]

Description

Would be great if I could cherry-pick commits from another branch. That would be very useful and often used feature in our company.

Version

GitHub Desktop version: 0.5.7
OS version: Microsoft Windows [Version 10.0.14393]

Steps to Reproduce

For example, I would like to select "cherry-pick..." and then it opens window where I could tag specific commits from another branches to my active branch.

And same thing step-by-step:

1. Select "Branch" tab from client's toolbar and select "cherry-pick...".
2. New window opens where I can tag specific commits from another branches to my active branch.

[nathanpitman]

Something I have requested many times for the old desktop client so adding my vote here to see this become a reality in the new GitHub Desktop. 👍

[kiuru]

@nathanpitman Do you have any good advice how to reproduce this new feature to project contributors? Is my example good enough or will come to mind some better one? I thought that was the best one.

[nathanpitman]

Here's how it worked in GitBox (my previous fave OS X Git client):

1. Pick branch you want to cherry pick from on the right in the title bar (development).
2. Commits which are not in the branch on the left (master) are denoted with a blue marker in the commit list
3. Right click on a commit with a blue marker and then choose 'Cherry-pick' from the context menu
4. This commits the 'commit' you cherry picked to the local branch
5. Switch branch on the right back to origin/master and push changes
6. Done

Pretty quick and easy. :)

[kiuru]

Sorry for my lack of understanding, but when I choose "origin/development" on the right in the title bar, does it means commits on below (in the middle of screen) will update according to this branch?

That function is not available at this moment on GitHub Desktop client. Is there anything else good reasons than cherry-pick why they should also add this function to client?

I mean I trying to figure out the most easily way to implement cherry-pick to the current version of client. :)

[nathanpitman]

I don't really care how it's implemented, so long as there is a low friction way to cherry pick a commit and merge it into another branch. :)

[loukia]

As an feature in UI, this could also be a improvement on current feature "Branch / Merge into current branch".

In 0.5.8, there is a text which says for example "This will bring in 7 commits from master". You can select "Merge into current branch" or close the window.

If there would be possibility to view and select (i.e cherry-pick) from these commits, it would be a great solution for this feature request.

[joshaber]

Thanks for the suggestion!

This idea is interesting for the future, but this is beyond the scope of our current roadmap.

I'm going to add the future-proposal label to this issue and close it out, so that we don't get overwhelmed with our backlog! We'll revisit these as part of our next planning session.

[MaximilienRedemption]

Cherry picking please.

[ratebeerjoet]

Yes, it would be great to be able to select and deselect which commits should be included. A simple checkbox and an option to "[ X ] De/Select All" at the top that you can click once to select all and click again to deselect all.

[hagaic]

Please add this feature

[dayleparker]

+1, I would love to see this implemented.

[thenninger]

+1 Yes, Please! I need this right now actually.

[sungjin0213]

+1 Please add cherry picking! I'm using two different apps for source repository because of this.

[okoethibm]

+1 here. These "advanced" features are the reason for using a stand-alone git client in the first place.

[ha404]

Please, let it be drag and droppable like in Tower :)

[madelineearp]

+1

[mandibuswell]

+1

[RomanHalaburda]

+1

[j-f1]

Please use the 👍 button on the original comment in the issue instead of commenting +1 so people subscribed to this issue don’t get unnecessary notifications.

[fabatista]

Yeap I agree!

[sffc]

+1, and please make sure to support the -x option in git cherry-pick.

[dbking77]

+1 for website support for cherry-picking one or more commits to make a new PR. Doesn't need to support conflict resolution, just allow "clean" cherry-picks in browser.

I often use cherry-pick to backport small fixes to other branches pretty often, and the command-line option is pretty tedious:

git checkout release_branch_1.0
git pull upstream release_branch_1.0  # make sure local branch is up to date
git checkout -b backport_fix_for_release_1.0   # make a new branch for back-port
git cherry-pick <some commit> <some other commit>  # grab fixes (sometimes more than one commit)
git push origin  backport_fix_for_release_1.0 
# now use github to make PR of backport_fix_for_release_1.0 against release_branch_1.0

[nathanpitman]

Having this in the desktop client or the website would be awesome. Cherry pick is such a useful feature, esp when working between many branches and larger teams.

[thenninger]

@kiuru Why is this issue closed? Is it not a valid enhancement?

[kiuru]

@thenninger This request has future-proposal label. Team GitHub said this is beyond the scope of their current roadmap, and they are going to revisit this later. GitHub didn't want to keep this on their backlog and that's why it's closed.

[kristianjaeger]

+1 please add this!

[thanhgb]

+1
I really want this feature, please add it in roadmap.

[AdamDiament]

Please add this!

[SylwesterZarebski]

Closed future proposal for more than 2 years ago. This Github representational client is almost dead by design (looks like it is modified by few persons in private time after work, not large corporation).

[alexanderadam]

This Github representational client is almost dead by design (looks like it is modified by few persons in private time after work, not large corporation).

What makes you think like that?
As far as I can see, it is actively maintained and by the GitHub staff.

IMHO it's just the policy that's "wrong". Closing an issue that isn't a wontfix (or similar) is the wrong way in my opinion.

Also the label future-proposal is not a relevant label for this project and I guess it is therefore additionally ignored.

As a user it is very difficult to follow the development here.
I have a similar impression of the Linux support here: it is still recommended to use the fork that lives outside of this repository (although it is working great).

[SylwesterZarebski]

Why? Because it is very bad habit to close issues to keep backlog simple (looks like a way to show managers: hey, there are N of M issues closed) and many of feature proposals lies in this grave. What is worse, most of them are essential to even think to use this software as console replacement.

[alexanderadam]

You probably didn't read properly.

1. I didn't ask "why".
2. I asked what makes you think that it "looks like it is modified by few persons in private time after work".
3. It's not feature proposal but future-proposal.

[SylwesterZarebski]

Because small private projects have many bad habits like this one. Isn't it obvious? Just look around.

PS. feature proposals is a typo, isn't it obvious? Check my first comment.

[niik]

Hey folks, let's keep this focused on the issue at hand please. We're well aware that cherry-picking is an important part of the toolbox for a lot of users and I understand that it's particularly meaningful for many of you who have responded in this thread. We've all had times when we wish the tools we use would just have that one feature that means the most to us.

If we can't maintain a respectful tone and stay focused on the issue we're going to have to lock this thread which isn't something we like to do as it eliminates the possibility for people to explain their use cases and offer insight that helps us prioritize features and provides context for how we can best solve the problem if/when we choose to pick up the issue.

If you'd like to add your +1 for this feature please do so by adding an emoji 👍 reaction at the top of this page.

I'm going to minimize recent comments that are either unrelated to this issue and/or aren't written in a respectful tone and I hope we can leave it at that.

[hron84]

@niik you (GitHub) promised to re-visit this feature later despite it's closed. However, it did not happened since two years. It's not surprising that if a core Git feature used by many developers missing from an official GitHub client makes users disappointed.

While I totally agree the comments without respectful tone can be avoided, please provide us a deeper insight when do you plan to take a look into this feature or what can we expect about it.

Also, closing a feature makes a bad message for developers that you aren't interested in this issue. GitHub on its own provides a numerous ways to manage your backlog either by making a Project that can contain issues only that meant to be on the backlog, or making Milestones. Closing isn't a neccessary part of this workflow and keeping these tickets open says us you are still keep this feature in your mind.

[daikhioualid]

+1 please add this!

[rahul-desai3]

+1 please add this feature

[pwp333]

This is the missing feature in github. Other competitors already have it.

[wreiske]

We need this for GitHub Enterprise Server!

https://github.community/t5/How-to-use-Git-and-GitHub/Feature-request-Cherry-pick-commits-from-UI/m-p/20745/highlight/false#M6125

[hottestchilipepper]

I made it. Please review the pull request. Thank you

[nathanpitman]

Superb @hottestchilipepper - what do we have to do to get this merged in @joshaber?

[say25]

Josh isn't working on Desktop right now. But @desktop/engineering should be able to weigh in.

[wreiske]

Now we just need it in GitHub.com and GitHub Enterprise Server! Thanks @hottestchilipepper for your work on the desktop app.

[outofambit]

Please see https://github.com/desktop/desktop/pull/9362#issuecomment-608653710 for context. Thank you!

[nerdneha]

Hello 🍒! We've reopened this issue to gather more information around your use cases for cherry-picking. We're interested in hearing the following from you:

• when you use cherry-picking today
• how frequently you cherry-pick
• is there anything you do consistently before or after cherry picking
• whether there's any required parts of cherry-picking by your team or repo (ex: my team/repo requires we do ____ as part of our process)

[ha404]

• I use it whenever I need to transfer a feature into another branch for whatever reason
• This occurs maybe ~1-2 a week
• I like to see if there are any conflicts that occur, if any, I'll choose to either abort or fix the conflicts
• I'm used to squashing changes into master so there aren't any precursor things we'd have to do

[say25]

@nerdneha In my own experience, we still use release branches for one of our deployables. In that case, we occasionally need to pull a changeset that already is on master into our release branch. This is a workflow we are looking to deprecate as we move to CI/CD and/or release tags

[davidcornewell]

We cherry-pick commits between branches several times a week. We require that a pull request be made targeting the branch to review. Bitbucket had a plugin PR Booster that let us cherry-pick to a branch VIA a pull request. We could then cherry-pick any additional commits to that PR branch.

[hottestchilipepper]

In service branches, it is very useful.
We have a project which is released to iOS and Android markets. We have 'master', 'service-ios', 'service-android' and 'hotfix'. We develop on 'master' branch. When some problems are noticed, we make a commit to fix it and push on 'master' branch. But if the problem is serious enough that users cannot use the application, we have to make hotfix. So we cherry-pick only some commits from 'master' to 'hotifx', to not to merged all changes from 'master' to application in service. Then merge 'hotfix' to 'service-ios' and 'service-android'.
Sometimes, some commits should be cherry-picked from 'master' to 'service-ios' or 'service-android' specifically, which is emergency by specific market's policy.

[dbking77]

We (used to) cherry-pick 3-4 times a week. Often a "smallish" bug fix the was found on the master branch would get back-ported to 1 or 2 "stable" releases that were in use by customers. There were almost never "merge" conflicts with these small cherry-picks
With this cherry-pick feature, we woul still wanted github hooks and PRs to be created for each one, so they got CI test, and possible approval.

[JonKohler]

While we are currently a large GitHub customer for the majority of our SCM estate, with the one large exception of a large mono repo that powers a key component of one of our products. That lives (for now) in Gerrit. I'd have to run some stats, but I'd say (easily) we use the "Cherry Pick" button in the Gerrit UI 100+ _per day_.

We've got a "mainline" branch of code that is our primary landing zone for code, and we've got release branches for many different iterations of code that we ship to customers.

The code landing into mainline could either feature/enhancements that will bake there until the next branch cut/release or they could be bug fixes/patches that have been found to impact customers.

We always have multiple release branches open, similar in concept to Windows 7, 8, 10, etc where customers may be running a particular release train and do not want to do a major upgrade to get one single patch release.

As such, When we have a customer-impacting bug/issue, we'll patch it in mainline, then use Gerrit cherry pick to port it over to a release branch (or many release branches).

Gerrit makes this _extremely_ easy since its just a single button. Gerrit (otherwise) is a bit of a PIA, so if it sniffs even the smallest of merge conflicts it will choke and die, but by and large the majority of these work just great.

[AdamDiament]

I use gitkraken for this - it has great features such as cherry picking and stashing capabilities, plus a solid modern UI lacking from something like source tree.

‫ב-9 באפר׳ 2020, בשעה 3:07, ‏‏Jon Kohler ‏[e-mail] כתב/ה:‬


While we are currently a large GitHub customer for the majority of our SCM estate, with the one large exception of a large mono repo that powers a key component of one of our products. That lives (for now) in Gerrit. I'd have to run some stats, but I'd say (easily) we use the "Cherry Pick" button in the Gerrit UI 100+ per day.

We've got a "mainline" branch of code that is our primary landing zone for code, and we've got release branches for many different iterations of code that we ship to customers.

The code landing into mainline could either feature/enhancements that will bake there until the next branch cut/release or they could be bug fixes/patches that have been found to impact customers.

We always have multiple release branches open, similar in concept to Windows 7, 8, 10, etc where customers may be running a particular release train and do not want to do a major upgrade to get one single patch release.

As such, When we have a customer-impacting bug/issue, we'll patch it in mainline, then use Gerrit cherry pick to port it over to a release branch (or many release branches).

Gerrit makes this extremely easy since its just a single button. Gerrit (otherwise) is a bit of a PIA, so if it sniffs even the smallest of merge conflicts it will choke and die, but by and large the majority of these work just great.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[kristianjaeger]

The main use case I can think of at the moment is when you want to only take your changes into master. So, if for example if someone has the typical feature -> develop -> master branch pattern there are times when folks do not follow a good practice and have things in develop too long and one might not know if they are stable or not to merge to master. So it would be great to reduce risk and cherry pick in those odd, unfortunate, circumstances. Thanks.

[mhanley00]

My clients would use GUI cherry-picking frequently to make text updates to config/json files that need to flow into multiple branches. Currently for these updates, they make the same changes to multiple branches (we can have up to 3 different dev branches with hooked up to different services at any given time) and it would be awesome if they could just click a button in GitHub to cherry-pick those same changes to multiple branches!

[CeuxDruman]

• when you use cherry-picking today: As part of our continuous delivery and agile/scrum processes, we have several "live" releases at the same time but at different environments or status, so every time we make a hot-fix for any of that releases, we have to cherry-pick that hot-fix to the other "live" ones (branches).

• how frequently you cherry-pick: Once/Twice per hot-fix.

• is there anything you do consistently before or after cherry picking: Before: Pushing a hot-fix to one of the live branches. After: Creating a new tag (optional: depending on the target release branch status)

• whether there's any required parts of cherry-picking by your team or repo (ex: my team/repo requires we do ____ as part of our process): It is required a Pull Request for approving the cherry-pick in the same way we do with a normal commit/branch.

[ladas-larry]

We use cherry-pick to include hotfixes into the release branch. That happens every week.

[shinchan305]

+1 please add this feature

[costin-dobrescu]

+1 please add this feature