Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> The perf framework lets the user run the test in an arbitrary repo,
> which makes writing a test for rebase a bit finicky. This one uses a
> perl script to determine a longest linear segment of history, that is,
> a range A..B which is completely linear. (For a full clone of
> git.git, this is the (whole) 'html' branch.) The number of commits
> that are rebased is capped at 50, however. That is, if A..B is more
> than 50 commits, it uses B~50..B instead.
>
> Having determined a suitable range, it then runs rebase with all
> combinations of rerere (on/off), -i / noninteractive, and -m / normal.
>
> Signed-off-by: Thomas Rast <trast@xxxxxxxxxxxxxxx>
> ---
I forgot to put the interesting part here:
Test this tree
------------------------------------------------------
3400.4: rebase -f (rerere off) 4.64(2.12+1.80)
3400.5: rebase -m -f (rerere off) 4.17(2.07+1.53) to .4: -10% ***
3400.6: rebase -i -f (rerere off) 4.51(2.30+1.57) to .4: -3% *
3400.7: rebase -i -m -f (rerere off) 4.51(2.31+1.57)
------------------------------------------------------
Significance hints: '.' 0.1 '*' 0.05 '**' 0.01 '***' 0.001
I did the change/significance manually here, so I might have made a
mistake in the exact numbers.
However, it's pretty obvious that 'rebase -f' is slow compared to
'rebase -m'. So slow in fact that the user would be better off running
an *interactive* rebase.
So what's the advantage of not using -m? I always thought it was
because plain rebase was supposed to be *faster* than -m, and I
confirmed this in an extremely scientific test on #git-devel:
[09 Mar 14:05] <charon> hrm, what's the advantage of straight rebase over 'rebase -m' ?
[09 Mar 14:06] <mhagger> charon: It's supposed to be significantly faster
[09 Mar 14:06] <charon> mhagger: ah thanks, that's what i suspected
This wasn't always the case; back in v1.7.0 you would see this picture:
Test v1.7.0
---------------------------------------------------
3400.4: rebase -f (rerere off) 3.75(2.12+1.18)
3400.5: rebase -m -f (rerere off) 4.05(2.29+1.32) to .4: +8% ***
This comes from the i18n support added in adc3b2b27..a9f578685, and from
43c2325 (am: use get_author_ident_from_commit instead of mailinfo when
rebasing, 2010-06-16).
Now I'm not really keen on hacking on git-am until it gets back its
performance, as for most uses it's probably still fast enough. But I
think one important question is: can we get rid of the
git-format-patch|git-am mode of git-rebase, which has historically been
a source of pain (see, e.g., the aforementioned 43c2325)?
Ok, perhaps not: certain features like --whitespace depend on it :-(
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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