Re: best practices against long git rebase times?

[John Keeping <john@keeping.me.uk>]

On Fri, Dec 04, 2015 at 04:05:46PM +0100, Andreas Krey wrote:
> our workflow is pretty rebase-free for diverse reasons yet.
> 
> One obstacle now appearing is that rebases simply take
> very long - once you might want to do a rebase there are
> several hundred commits on the remote branch, and our tree
> isn't small either.
> 
> This produces rebase times in the minute range.
> I suppose this is because rebase tries to see
> if there are new commits in the destination
> branch that are identical to one of the local
> commits, to be able to skip them. (I didn't
> try to verify this hypothesis.)
> 
> What can we do to make this faster?

I'm pretty sure that you're right and the cherry-pick analysis is where
the time is spent.

I looked into this a couple of years ago and I have a variety of
(half-finished) experiments that might improve the performance of this:

	https://github.com/johnkeeping/git/commits/log-cherry-no-merges
	https://github.com/johnkeeping/git/commits/patch-id-limit-paths
	https://github.com/johnkeeping/git/commits/revision-cherry-respect-ancestry-path
	https://github.com/johnkeeping/git/commits/patch-id-notes-cache
	http://comments.gmane.org/gmane.comp.version-control.git/224006

I have no idea if any of these changes will apply to modern Git (or if
some of them are even correct) but I can try to clean them up if there's
interest.

The commit for patch-id-limit-paths includes some numbers that might be
relevant for your case:

    Before:
    $ time git log --cherry master...jk/submodule-subdirectory-ok >/dev/null
    
    real    0m0.373s
    user    0m0.341s
    sys     0m0.031s
    
    After:
    $ time git log --cherry master...jk/submodule-subdirectory-ok >/dev/null
    
    real    0m0.060s
    user    0m0.055s
    sys     0m0.005s