Re: time needed to rebase shortend by using --onto?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 26, 2021, 22:18 UTC
- Message-ID
- <xmqqim35b0kz.fsf@gitster.g>
- In-Reply-To
- <20210526100932.2hw4rbazgvd6mzff@pengutronix.de>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
Show 36 quoted lines
> 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).