Github website should support cherry-picking.
mirek opened this issue · comments
Github website should support cherry-picking by going to branch, then cherry-pick, select one or more commits and apply.
Even more powerful with :-) #200
@************ maybe but the beauty of cherry-pick is that, when can be cleanly applied, it doesn't require any extra UI elements.
Cherry picking should be used with care. If you cherry pick then you introduce the same change multiple times in your repo. If this change causes a merge conflict later on then you need to resolve the merge conflict multiple times...
@larsxschneider sorry I don't see what you mean, anything can "cause merge conflicts later on".
I'd like to see cherry-picking in github web ui, for commits that you choose quickly, only for commits that can be cleanly applied, with minimal UI (just picking a list of commits and applying).
It's useful because sometimes there is a hot fix for other branches but you're currently working on a project locally, ie. your web app is running and you don't want to stop server, change branches, cherry pick commits and push that - in github ui you can do it very quickly with nice autocomplete/list of recent commits that are not merged yet etc.
This was removed in 2012: https://github.com/blog/1091-spring-cleaning
🎩/T @klaustopher via #651 (comment)
+1 for cherry-picking functionality. As a maintainer, every time I merge a pull request through the UI, I have to go in the code and cherry-pick the merged commits to the stable branches. This is an ugly manual process with lots of fragile copy-pasting.
What I would expect from the UI: after having pressed the "merge" button in the pull request, a "cherry-pick individual commits" button appears with a pull-down menu "to branch xxxxxx". After the button is pressed, the commits are presented in a new window, with tick-boxes next to them: "select which commits you want to cherry-pick to branch xxxxxx".
I'll be monitoring this thread.
At a high level, there are legit use cases for cherry-picking commits. The ones on this thread are but a few of many. That's why git introduced the concept. Unless someone wants to argue the makers of github made a mistake by doing so, it's odd that this incredibly useful - and conceptually pretty simple - functionality would be removed from github.
Gitlab support cherry-picking in the UI.
@github where are you?
Would like to see this. I'm in an airport, have only my cell, would like to use web interface to make a new branch, cherry pick a few commits off another branch and then merge these.
3rd anniversary day is coming close. Would be great to have this fixed that day.
Ridiculous that we still can't Cherry-Pick.
+1 for cherry-picking. It's a must-have.
+1
Oh come on guys @github, do it already. We also want direct messaging back with privacy options.
DO IT! PLEASE!
I thought this already existed but it's a rude shock that I can't create a branch and merge the cherry picked commits . I have to pull up a cli to bring this up . Atleast provide a CLI interface if not UI for cherry pick .
+1 I am also finding this extremely annoying.
Finally I found the one killer reason to switch to gitlab.
+1 ... ridiculous that you added multi-line comments before just adding a simple UI button to cherry pick a PR to another branch. Literally just copy Gitlab, its a great feature. Have an intern do it.
Common guys! Fix this already!
Any progress?
Ping, can we make this happen with GitHub Action, automatically make a cherry-pick PR based on a comment?
Example:
/cherry-pick dev
Glad to see that I am not alone thinking that...
For squash merge, it's better to have a cherry-pick button on PR.
This is why I use Gitlab, cant believe Github UI doesnt support cherry pick
Still issue in 2020 (after 4 years), even though it is in the top15 upvoted issues. I wonder why it's been ignored for so long...
Simple. Github doesn’t value the wants/needs and opinions of its customers.
That’s why more and more people are moving to Gitlab.
You can also migrate to TFS 2017 and get Cherry Pick!
I am still waiting.......
Workaround:
git remote add other https://example.link/repository.git
git fetch other
git checkout -b new-branch other/branch
git log
-- Pick commit id
git checkout oldBranch
cherrypick using commitId
Please support cherry-picking via GitHub UI.
This is a very handy feature in git for when having to apply a hotfix to multiple support branches in a gitflow environment.
What is the financial cost of implementing this feature? To rephrase, what is the minimum feature crowdfunding target to motivate the implementation of this feature, in USD? (Including design, review, implementation, more review, testing, even more review, iterate, improve, maintain forever...)
Let's say if I chip in $100 USD, it may take about 1000 other users to reach the target.
@kinchungwong No funding issue, but it has a huge runtime cost implication, as git cherry-pick picks changes, not commits, and creates new commits to accommodate those changes.
@erkinalp I don't understand your comment. Both GitLab and Gerrit have this in the UI. I understand those VCS work differently, just I don't get why if this development is "fundable", why the amount of time to develop a MVP to do something akin to "duplicate this PR in another branch" would be prohibitive.
This would really speed up productivity!!
Any update about this enhancement ? I still running the process manually with git-scm :'(
+1 from me too!
cherry-pick right from the GitHub web interface would be great!!
it's 2021 already :)
+1 from me too!!! its 2021.. This is pitiful!!!Gitlab is better???
It's ok, I can wait.
ps. I have two kids now!
It would help!!!!!
This would really improve on number of merge conflicts to solve when sharing intermediary commits for a parallel dev. Without you need to lose time taking care of ordering changes all the time in order to avoid conflicts when pulling in master. Having used gerrit before, I find github being less productive from certain points of view. Might be more organized, but makes you lose more time.
A sign of progress: cherry-picking has come to Desktop. Hopefully more to come! 🚀
Great job +1
Also if you want automated cherry picking you could use labels for them like for example you got a pr on main that is a hotfix and you want to cherry pick that to the release/2.0 branch and to the release/1.0 branch, what do you do?
Add an cherry-pick: release/2.0 and an cherry-pick: release/1.0 label and have mergify rules handle the rest.
😆
At least it can be automated that way as well.
And to merge the hotfix to main you could use mergify for that too, and have the users with write access that you want only to have merge ability to add an automerge label and then the rule would trigger merging the pr(s).
plz
Hi folks, Emma from GitHub here. Thanks so much for all your feedback!
We've been working on enabling cherry-picking through the web UI, but we'd still need to take on a bit more work to get it ready for public release. To help us figure out how to prioritise that, I wondered if some of you would be up for testing what we've built so far and letting us know what you think?
Absolutely, I'm up for that, count us in
Oh ye that would be perfect for those who maintain https://github.com/python/cpython as well.
Also I would also love it if they could trigger a cherry pick on unmerged pr's too from within the PR interface as well on the web UI.
At least add a button for PRs saying create cherry-pick pr for branch and then it pops up a box that contains a dropdown list of branches to base the cherry-pick off of then create a new branch and pr using the same PR title and text inside it's message from the orignal PR.
I think most of this would benefit the cpython devs and also deprecate the bot they use to backport changes to older python releases.
Great - this should now be enabled for all those that github.com/<org or user>/<repo>/commit/<sha>). I'll be in touch for any feedback in a week or two, but in the meantime keep me posted with any thoughts 🙏 😄
Great - this should now be enabled for all those that
👍 'd me. You can find the cherry-pick button on the top right of any commit page (github.com/<org or user>/<repo>/commit/<sha>). I'll be in touch for any feedback in a week or two, but in the meantime keep me posted with any thoughts🙏 😄
Dropped everything this morning to try this out and ran into a few walls, here's my feedback
Things I like:
- There is a branch filter that is dynamic. At least in the version of Gerrit I use, you manually have to type in the branch, which is a pain.
- It's smart enough to know when it will fail in advance. A crude test with creating a branch from master and then trying to cherry-pick the very top commit gets Unable to cherry-pick this commit because the changes already exist on the branch. ... which is expected.
- When things are "clean" (no conflicts, ready to roll, no protection, all good), it's a very fast workflow.
Things I don't like:
- if you try to cherry-pick to a branch that has a merge conflict, it doesn't help you resolve that conflict that you might get in the PR merge conflict workflow. Instead, you get an unceremonious error: Unable to cherry-pick this commit because there is a conflict with the selected branch.
- If you try to CP into a protected branch, you hit a similar wall with: Unable to cherry-pick this commit because the selected branch is protected.
- You don't get an opportunity to change the commit-msg. This is somewhat common in many cherry-pick workflows where you might need to fill in some information on why that specific commit is being cherry-picked, such as a defect ID or some note about why it applies to the target branch
- lastly (this is probably a show stopper for some) - It literally just "grips it and rips it", so if you have many commits in a series and perhaps would want those review prior to commit (either by people or by precommit checks API integrations, like build, test, deploy workflows for the target branch), you don't get that ability at all. This is likely good for some use cases, but for teams rallied around precommit/review workflows, it's a non-starter I'd bet.
The expected behavior IMHO should be
- Give an option to commit direction OR start a new branch + PR - this is similar to the manual commit workflow that the UI already has today ... if you just click edit in the UI and then it asks you commit direct or new branch +PR. You could then cherry-pick all of the commits in a series into a temp branch and into a PR
- For such "direct" commits, help out merge conflicts just like the PR merge conflict workflow
- For picks to protected branch, offer the user a workaround (likely this branch is protected against direct commits, start a new branch and PR, click yes to go!)
- For direct commits, offer the chance to edit the commit msg
Also, semi-related nit, if we're adding a cherry-pick button to the UI for the individual commit and not an entire PR, it would be nice to have a revert button in the UI for an individual commit too. This is something that gerrit has that is quite useful and just so happens to be directly next to the CP button in the PolyGerrit UI. This really hasn't been a huge issue in GitHub since the unit of focus was a PR and the revert button is there, but if we're drilling focus down to any random commit, having revert on a commit level would be nice too
Hi @emmaviolet ,
Great ! working fine.
Is there any feature to enable multiple commits selection for cherry-pick?
It would be great to enable it from github.com/<org or user>/<repo>/commits/<branch-name>
Thanks.
This is excellent feedback. Thanks so much!
No ability yet for multiple commits selection @yassinesefi - hope we'll be able to address that as a future improvement, along with improvements to the merge conflict flow and commit message changes suggested by @JonKohler. The show-stopper we'll try to address soonest
Hi folks, Emma from GitHub here. Thanks so much for all your feedback!
We've been working on enabling cherry-picking through the web UI, but we'd still need to take on a bit more work to get it ready for public release. To help us figure out how to prioritise that, I wondered if some of you would be up for testing what we've built so far and letting us know what you think?
Give me a
👍 if so🙏
Yes I would love to be able to test this!! Working on the go from my iPhone or iPad Pro, Would be great to be able to use this feature when I’m not at a proper desktop computer…
I wish there was also an easy button on a branch as well to rebase that branch from another branch as well which basically then would take all commits to that branch and re-apply them on top of the changes from another branch from the web UI as well (at least on the commits tab in a PR would be nice)
@emmaviolet Hopefully I didn't miss the boat on feedback here. The single commit cherry-pick works well. If people are needing one off single commit cherry-picks, I think this will work great, and works in a pinch for doing more than one.
I really would like to see this be able to cherry-pick a whole PR/branch and create a new PR for review of the cherry-pick before "letting it rip." I agree with sentiments above that the typical workflows need automations to happen, and the best way to be consistent about that is with a new PR process for the cherry-pick. Being able to cherry-pick a whole existing, merged PR would help immensely for back-porting hot fixes and security releases to release branches.
Really glad to see any work at all on this functionality. Thanks for taking input!
@emmaviolet Hopefully I didn't miss the boat on feedback here. The single commit cherry-pick works well. If people are needing one off single commit cherry-picks, I think this will work great, and works in a pinch for doing more than one.
I really would like to see this be able to cherry-pick a whole PR/branch and create a new PR for review of the cherry-pick before "letting it rip." I agree with sentiments above that the typical workflows need automations to happen, and the best way to be consistent about that is with a new PR process for the cherry-pick. Being able to cherry-pick a whole existing, merged PR would help immensely for back-porting hot fixes and security releases to release branches.
Really glad to see any work at all on this functionality. Thanks for taking input!
I agree, also I know of many people who require to have cherry-pick PR's made for backports before the main change gets merged into their default branch so then they can then have their CI merge train their servicing fixes whenever they (only have it where a person with write access can press make cherry-pick PR to branch: and select which branch they want it to target) and then they also have it where servicing fixes automatically get merged via "merge trains" which checks multiple PR's at once for merge-ability and CI passing status before actually merging each one.
Hopefully I didn't miss the boat on feedback here.
@ricka not at all! Thanks so much for sharing. And @AraHaan this is very helpful context.
Just to share where we're at now, for full transparency. Our team has a (roughly) two week timebox on projects - we can pick up "quality of life" improvements more easily than other teams - but that's because we don't invest a ton of time in them.
Suffices to say, we misjudged the commitment we were taking on here, and it spiralled to several times what we'd usually spend on a project. That's fine, but now we're pausing to make sure we move forward with enough signal - if we're going to spend another two months on it, it has to be really useful! 😸
Currently, it looks like we're not quite there. Alongside the folks in this thread, we've opened this up to all GitHub and Microsoft employees, but seeing very little use. And the additional work required to make this satisfy all the additional use cases is not nothing either (mostly thanks to many unhappy paths)
So it's on pause for the time being - will stay dark-shipped for those on this thread, and we'll review in another couple of months to see whether we can pick this up again.
Thanks so much for all the feedback and help so far. I will keep you posted!
@emmaviolet Really love the transparency and honesty...please keep it up! And yes, I think there is a good bit of work involved to pull off this feature successfully. But if you are looking for inspiration within Microsoft, please reach out to the Azure DevOps team. They had an article up for a while (removed sometime this year unfortunately, but still accessible here that talks about how ADO implemented this and how the ADO team uses it for their "Release Flow". In fact, I'd wager that most internal folks that want this are just using ADO since it has had this functionality for some time. It's also something GitLab provides.
I don't mean to say that any feature that other services offer is worth copying wholesale, but I do think this is a very very useful feature that people would love to see implemented in Github too and that you might have some folks within Microsoft that would evangelize it as well.
@emmaviolet I think I missed a memo
we've opened this up to all GitHub and Microsoft employees, but seeing very little use
This sentence was the first I heard the feature was available to me. I might have used it before because it avoids redoing squashes as we need to do w/ our "backport bot" (see https://github.com/dotnet/aspnetcore/blob/main/.github/workflows/backport.yml and https://github.com/dotnet/aspnetcore/tree/main/eng/actions/backport). Unfortunately, the first time I tried the feature, I hit the dreaded Unable to cherry-pick this commit because the selected branch is protected. message and wasn't able to recover by creating a new branch and opening a PR.
Also hit Unable to cherry-pick this commit because there is a conflict with the selected branch. when targeting a different branch. Would have loved to be able to fix things up in the GitHub UI -- as I can after hitting some conflicts in PRs.
Bottom line, awareness about and gaps in this feature are likely limiting GitHub and Microsoft usage too.
Bottom line, awareness about and gaps in this feature are likely limiting GitHub and Microsoft usage too.
@dougbu I 100% agree with you. In general, I'd say, we are not great either at highlighting new features to existing users or at onboarding new users to existing users. We are working on it, but we're not there yet. This one hasn't even made it to our changelog, because it's not publicly shipped.
Discoverability of this feature in particular is definitely a challenge, and almost certainly limiting its usage. I expected to navigate to it through looking at the commits in a given PR, for example (and that might, regardless, help more people to notice it, as that's a common flow). Is there anywhere else you'd expect to see it?
Think we probably could invest a few more days to solve some of the discoverability challenges, but fixing the meatier issues without better signal is going to be a challenge (I do recognise the chicken-and-egg problem here, but it's still hard to justify).
Discoverability of this feature in particular is definitely a challenge, and almost certainly limiting its usage. I expected to navigate to it through looking at the commits in a given PR, for example (and that might, regardless, help more people to notice it, as that's a common flow). Is there anywhere else you'd expect to see it?
How about right at the end of this but right before it shows the number of commits before (and counting) whatever the currently viewed commit is in this view?
As for PR's I think a separate section from commits in the commits tab to cherry pick (I think it should also automatically create PR too when pressed and selected to a target branch and inside that make the title almost exactly match the original pr but add in [<branch name>] without the < and >'s) and message inside the same as the original as well:
However there is another issue, what if the PR has more than 1 commit? Will it cherry-pick all of them or just a single commit? If a single commit could it squash first then cherry-pick the squashed result (without sqausing it on the actual original PR)?
Both Azure DevOps and Gitlab put this right next to the revert button on a merged PR, and I think that makes a lot of sense.
ADO:
Gitlab:
This would need to work for multiple commits though. Additionally, I saw @AraHaan brought up cherry-pick before merge. I think you have to go deeper into context menus to make that happen in ADO and I'm not sure it is possible in Gitlab.
@emmaviolet I'm excited to see this is going to be implemented in the web interface and I would love to be able to test it. I had an altercation with someone in the past because someone included the exact code I had written somewhere without any mention of me, and I hope this addition can fix some future troubles like that 😅
Having this implemented in the web interface would be a game-changer, especially for teams investing heavily in other Github integrated solutions.
For instance, we use Actions for turnkey deployment to our cloud. Cherry-picking would give me the ability to still mandate all engineers PR against dev, even when a patch needs to make it to master outside release schedule. I can just cherry-pick the patch's commit to staging and then master (from my phone while I'm on an airplane!!), and the patch will deploy to production. That's a kind of fast and loose scenario perhaps, but I think shows how critical this feature is to teams taking advantage of other integrated Github solutions.
I have some slightly sad news on this, which is that after much team discussion, we decided to unship this feature yesterday.
Why?
In the six weeks since we shipped the feature to our staff, and to some of you, we saw very little usage. Less than 100 cherry-picks were successfully completed through the web UI.
We saw an equal number of failed cherry-pick attempts. About half of these failed due to merge conflicts, and we're not able to commit the time we'd need to solve that right now.
We also looked at the number of users currently using this feature on Github Desktop, which introduced it some months ago at the same time as we did. Theirs is a much fuller-featured implementation, but still doesn't see as much use as we'd expected it too. Further, when we looked into the Desktop data, we saw that a significant proportion of their usage was from users cherry-picking multiple commits. That's another use case that we don't quite have the capacity to address.
Finally, we looked into the discoverability issues highlighted in this thread. We think we made a misstep here, and probably should have tackled this issue sooner, but we don't think that enhancing the discoverability of this feature can meaningfully improve usage in the absence of other more substantive fixes.
What next?
The team tackled many challenges in bringing this feature to production, and we'll be keeping some of that in the codebase. It will be much easier for another team to tackle this in the future through building off the work we've done.
For now, though, we've unshipped the frontend code, and are focusing our energies on other projects. Hopefully many of those will benefit you too :-)
I would bet some dollars that if it was shipped wider and publically announced, you'd see more usage.
That plus a weeeeeee bit more polish from my comments and the ones immediately between mine and yours and we'd be completely golden (like cherry picking entire PRs / multiple commits at once, etc). Just having CP on a single atomic commit is like a 10th of the battle :(
I would see (or expect) major use of this feature by @dotnet and @microsoft if it was in public preview.
@emmaviolet I loved this feature, and used it daily, was it just removed from my account?
While I appreciate the reasoning behind this decision I resoundingly disagree. @JonKohler made some excellent points about increasing visibility, and beyond that it is sad to see GitHub abandoning its power users in favor of a (in my opinion misinformed) survey approach. I really hope this criticism makes it to the decision makers involved.