Re: rebase vs rebase -i

[Jay Soffian <jaysoffian@gmail.com>]

On Thu, Feb 4, 2010 at 7:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I think Dscho's point is that cherry-pick internally runs the same
> merge-recursive.

Ah hah, that's what I was missing. Thank you.

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

Indeed, the difference is painful on a largish tree (910M after gc
--aggressive, 39k files). Best of 3 runs for each of these:

$ time git rebase --onto HEAD~11 HEAD~10
First, rewinding head to replay your work on top of it...
[...]
real	0m11.164s
user	0m2.671s
sys	0m4.836s

$ time git rebase -m --onto HEAD~11 HEAD~10
[...]
real	0m40.507s
user	0m17.848s
sys	0m16.052s

$ time GIT_EDITOR="sed -i -e 1d" git rebase -i HEAD~11
[...]
real	0m27.758s
user	0m12.615s
sys	0m13.134s

It looks like there's room for improvement to rebase -m. (2.53 Ghz
Core 2 Duo Macbook Pro, 4GB memory.)

j.