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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html