From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 05 Feb 2010 00:45:21 GMT
Subject: Re: rebase vs rebase -i
Message-ID: <7vmxzose72.fsf@alter.siamese.dyndns.org>
In-Reply-To: <76718491002041157o37de139brb7995076274375aa@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

> On Thu, Feb 4, 2010 at 1:46 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Both "rebase -i" and "rebase -m" are really a cherry-pick in a loop.
>
> Well then I'm still confused. I see where pick_one() in
> git-rebase--interactive.sh is using cherry-pick.
>
> But call_merge() in git-rebase.sh is using git-merge-recursive (absent
> specifying another strategy).
>
> ?

I think Dscho's point is that cherry-pick internally runs the same
merge-recursive.

When you have a change C based on its parent C^ and want to replay that
effect on a (possibly unrelated) commit A, you would run three-way merge,
merging C into A as if C^ is the common ancestor.  The rebase script
cherry-pick, and revert all work with the same principle (for revert
obviously you would swap C and C^---you are applying the effect of going
from C to C^ in that case).

And no, "format-patch --stdout | am -3" pipe in the normal rebase codepath
will stay unless you can produce a benchmark that says the performance of
merge machinery is good enough these days.  Back when "rebase -m" was
introduced, it wasn't.