Re: time needed to rebase shortend by using --onto?

[Elijah Newren <newren@gmail.com>]

On Wed, May 26, 2021 at 3:13 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> Hello,
>
> I have a kernel topic branch containing 4 patches on top of Linux v5.4.
> (I didn't speak to the affected customer, so I cannot easily share the
> patch stack. If need be I can probably anonymize it or ask if I can
> publish the patches.)
>
> It rebases clean on v5.10:
>
>         $ time git rebase v5.10
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Successfully rebased and updated detached HEAD.
>
>         real    3m47.841s
>         user    1m25.706s
>         sys     0m11.181s
>
> If I start with the same rev checked out and explicitly specify the
> merge base, the rebase process is considerably faster:
>
>         $ time git rebase --onto v5.10 v5.4
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Performing inexact rename detection: 100% (36806539/36806539), done.
>         Successfully rebased and updated detached HEAD.
>
>         real    1m20.588s
>         user    1m12.645s
>         sys     0m6.733s
>
> Is there some relevant complexity in the first invocation I'm not seeing
> that explains it takes more than the double time? I would have expected
> that
>
>         git rebase v5.10
>
> does the same as:
>
>         git rebase --onto v5.10 $(git merge-base HEAD v5.10)
>
> . (FTR:
>
>         $ time git merge-base HEAD v5.10
>         219d54332a09e8d8741c1e1982f5eae56099de85
>
>         real    0m0.158s
>         user    0m0.105s
>         sys     0m0.052s
>
> , 219d5433 is v5.4 as expected.

That does seem surprising, though if an automatic gc completed between
the two commands that could certainly explain it.  If that theory is
correct, it would suggest that it'd be difficult for you to reproduce;
running again with either command would give you something closer to
the lower time both times.  Is that the case?  (Also, what's the
output of "git count-objects -v"?)

>
>         $ git version
>         git version 2.29.2
>
> That's from the Debian package 1:2.29.2-1~bpo10+1 on a Debian 10 box.)
>
> Best regards
> Uwe

I'd love to try this with git-2.32.0-rc1 (or even my not-yet-upstream
patches that optimize even further) with adding "--strategy=ort" to
your rebase command to see how much of a timing difference it makes.
Any chance the patches could either be published, or you could retry
with git-2.32.0-rc1 and add the --strategy=ort command line option to
your rebase command(s)?

Elijah