Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> 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).
