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

[Junio C Hamano <gitster@pobox.com>]

Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:

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

There is a voodoo called fork-point detection that walks back the
reflogs and repeatedly computes merge bases, and giving --onto to
explicitly give a commit on which the history is transplanted should
remove the need to do the computation, so that is a possibility.

But according to the manpage, it should not kick in for invocations
in the above example that specify the <upstream> (the
rebase.forkpoint configuration variable can clobber this default).