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

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