Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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.
Just for fun, I pulled from the kernel tree. Its tip is at fc76be4 (Merge
master.kernel.org:/home/rmk/linux-2.6-arm, 2010-02-04), which is a merge
of a subsystem tree into the mainline.
I tried to rebase HEAD^2 (i.e. subsystem change) on top of HEAD^1 (the
state Linus merged that subsystem change into). Either way, the
experiment is to linearlize a side branch that has 16 patches:
The experiment is to take a history of this shape:
--A-...--N--O--P master^2 = test (subsystem tip)
\
---X--Y master
master^1
and turn it into a history of this shape:
--A-...--N--O--P master^2 = test (subsystem tip)
\
---X--Y master
\
A'-B'-...O'-P' (rebased tip)
The tree at rebased tip P' must match the merge Y, of course.
First, to prepare:
$ git checkout -b test master^2 ;# at the tip of subsystem
$ git checkout HEAD^0 ;# detach so that I can easily repeat
Best of 5 runs on my box are:
$ git reset --hard test && time git rebase master^1
real 0m3.060s
user 0m1.976s
sys 0m0.812s
vs
$ git reset --hard test && time git -m rebase master^1
real 0m19.060s
user 0m15.025s
sys 0m3.564s
The numbers are understandable; the series touches only 12 paths among
31.5k paths, so applying patches has to be faster.
I have a plan to make a merge go faster by using a yet another merge
strategy, but that has been backburnered for now.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html