Re: rebase vs rebase -i

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2010, 01:18 UTC
Message-ID: <7vy6j8pjj8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vmxzose72.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> 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.