Re: rebase vs rebase -i

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2010, 00:45 UTC
Message-ID: <7vmxzose72.fsf@alter.siamese.dyndns.org>
In-Reply-To: <76718491002041157o37de139brb7995076274375aa@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 11 quoted lines

> 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.