Symmetric of rebase / more intelligent cherry-pick

Symmetric of rebase / more intelligent cherry-pick

[Lionel Elie Mamane]

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

Re: Symmetric of rebase / more intelligent cherry-pick

[Junio C Hamano]

Lionel Elie Mamane <lionel@mamane.lu> 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.

Re: Symmetric of rebase / more intelligent cherry-pick

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Lionel Elie Mamane <lionel@mamane.lu> 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?

Re: Symmetric of rebase / more intelligent cherry-pick

[Jonathan Nieder]

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