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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
