Open mirek opened 8 years ago
Even more powerful with :-) https://github.com/isaacs/github/issues/200
@cirosantilli 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 https://github.com/isaacs/github/issues/651#issuecomment-215008484
+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
:+1:
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 π'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 π π
Github website should support cherry-picking by going to branch, then cherry-pick, select one or more commits and apply.