# Symmetric of rebase / more intelligent cherry-pick 4 messages from 2011-10-11 to 2011-10-11. Participants: Lionel Elie Mamane, Junio C Hamano, Jonathan Nieder. Thread: https://gitlist.dev/t/28648 ## Lionel Elie Mamane, 2011-10-11 15:54 Subject: Symmetric of rebase / more intelligent cherry-pick Message-ID: <20111011155444.GB14417@capsaicin.mamane.lu> URL: https://gitlist.dev/e/20111011155444.GB14417%40capsaicin.mamane.lu ``` Hi, I was thinking about a sort of symmetric to rebase, a kind of "intelligent" mass cherry-pick. For the sake of example let's call it "basere", although a better name would have to be found. While git rebase UPSTREAM moves the *current* branch (and any commit in it, but not in UPSTREAM) on top of UPSTREAM, git basere UPSTREAM would "cherry-pick" all commits in UPSTREAM that are not in HEAD to the current branch. git cherry-pick ..UPSTREAM *nearly* does what I want, except that it lacks rebase's intelligence of skipping commits that do the same textual changes as a commit already in the current branch. So maybe it should be an option to cherry-pick rather than a new command? E.g. --skip-same? What about making it cherry-picks *default* behaviour? Why do I think it is useful? Take the case of a developer following two different origins A and B, and B uses rebase (not merge) to integrate changes from A, but not as often as one would like. A could for example be the "official" tree (e.g. linux Linus tree), and B a feature branch of a developer that is meant to eventually go into A "cleanly" at some future time and A's policy is that one has to rebase before sending a merge request. Then another developer wants to keep up with changes from *both* A and B. So, the situation could look like: A---A---A remotes/A/master / X---X---B0---B1---L master \ B0---B1---B2--B3 remotes/B/master So one does "git rebase remotes/A/master master" and one gets A---A---A---B0---B1---L master / X---X \ B0---B1---B2--B3 remotes/B/master I'd like to go to the situation: A---A---A---B0---B1---L---B2--B3 master / X---X \ B0---B1---B2--B3 remotes/B/master Without having to manually find the cutoff point "B2" (or worse, if the history is more messy than that, as in: A---A---A---B1---L master / X---X \ B0---B1---B2--B3 remotes/B/master ) The best way I have found to do that is: git fetch B git checkout --no-track -b TMP remotes/B/master git rebase master git checkout master git merge --ff-only TMP git branch -d TMP or less commands but more messy/fragile (and more work for git): git fetch B git tag TMP git rebase remotes/B/master git rebase TMP git tag -d TMP but that is rather onerous for something that should be just one command. So what are your thoughts on that? - Good idea? Would you take a patch that does something like that? - Should it be cherry-picks's default behaviour? - An option to cherry-pick? - A new command? What name? Maybe "multi-cherry-pick"? - An option to rebase, e.g. "--pull" or "--incoming" or "--here"? ("--pull" is probably too confusing wrt to "git pull"; people will have trouble remembering which is which between "git pull --rebase" and "git rebase --pull"...) -- Lionel ``` ## Junio C Hamano, 2011-10-11 19:36 Subject: Re: Symmetric of rebase / more intelligent cherry-pick Message-ID: <7v8vorfhhu.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v8vorfhhu.fsf%40alter.siamese.dyndns.org In-Reply-To: <20111011155444.GB14417@capsaicin.mamane.lu> ``` Lionel Elie Mamane writes: > git cherry-pick ..UPSTREAM > *nearly* does what I want, except that it lacks rebase's intelligence > of skipping commits that do the same textual changes as a commit > already in the current branch. I think in the longer term "--ignore-if-in-upstream" that is known only to format-patch, which is the true source the intelligence of rebase you observed comes from, should be factored out into a helper function that can be used to filter output from get_revision() in other commands, or perhaps get_revision() itself might want to learn it. I say "or perhaps might" above, because I do not think the general revision traversal machinery used by the log family (which cherry-pick's multi-pick option relies on) has enough information to decide what the caller means by "upstream" at the point setup_revisions() is called. ``` ## Junio C Hamano, 2011-10-11 21:28 Subject: Re: Symmetric of rebase / more intelligent cherry-pick Message-ID: <7vty7fdxql.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vty7fdxql.fsf%40alter.siamese.dyndns.org In-Reply-To: <7v8vorfhhu.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano writes: > Lionel Elie Mamane writes: > >> git cherry-pick ..UPSTREAM >> *nearly* does what I want, except that it lacks rebase's intelligence >> of skipping commits that do the same textual changes as a commit >> already in the current branch. > > I think in the longer term "--ignore-if-in-upstream" that is known only to > format-patch, which is the true source the intelligence of rebase you > observed comes from, should be factored out into a helper function that > can be used to filter output from get_revision() in other commands, or > perhaps get_revision() itself might want to learn it. We actually have half of that filtering in "--cherry-pick" that was introduced in d7a17ca (git-log --cherry-pick A...B, 2007-04-09). Perhaps the recent cherry-pick that allows multiple commits to be picked should use that option (i.e. a "log --cherry-pick --right-only ..@{u}" equivalent) when coming up with which commits to apply? ``` ## Jonathan Nieder, 2011-10-11 22:23 Subject: Re: Symmetric of rebase / more intelligent cherry-pick Message-ID: <20111011222138.GA3768@elie.hsd1.il.comcast.net> URL: https://gitlist.dev/e/20111011222138.GA3768%40elie.hsd1.il.comcast.net In-Reply-To: <7vty7fdxql.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano wrote: > We actually have half of that filtering in "--cherry-pick" that was > introduced in d7a17ca (git-log --cherry-pick A...B, 2007-04-09). > > Perhaps the recent cherry-pick that allows multiple commits to be picked > should use that option (i.e. a "log --cherry-pick --right-only ..@{u}" > equivalent) when coming up with which commits to apply? No UI ideas from me, but I have a script like this sitting in $HOME/bin: base=$1 topic=$2 git rev-list $base..HEAD | git diff-tree -s --pretty=raw --stdin | sed -ne 's/(cherry picked from commit \([0-9a-f]*\))/\1/p' | xargs git cherry-pick -x -s \ --cherry-pick --right-only --no-merges HEAD...$topic \ --not $base ```