Uwe Kleine-König [off-list ref] 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).
Hello Junio,
On Thu, May 27, 2021 at 07:18:52AM +0900, Junio C Hamano wrote:
Uwe Kleine-König [off-list ref] writes:
quoted
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).
FTR: I don't have this variable set in the two repositories that show
the different timings.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |