Re: q: faster way to integrate/merge lots of topic branches?

From: Ingo Molnar <mingo@elte.hu>
Date: Jul 23, 2008, 14:09 UTC
Message-ID: <20080723140959.GB9537@elte.hu>
In-Reply-To: <20080723174140.b749191a.vsu@altlinux.ru>

* Sergey Vlasov <vsu@altlinux.ru> wrote:

Show 24 quoted lines

> On Wed, 23 Jul 2008 15:05:18 +0200 Ingo Molnar wrote:
> 
> > Anyone can simulate it by switching to the linus/master branch of the
> > current Linux kernel tree, and doing:
> >
> >    time for ((i=0; i<140; i++)); do git-merge v2.6.26; done
> >
> >    real    1m26.397s
> >    user    1m10.048s
> >    sys     0m13.944s
> 
> Timing results here (E6750 @ 2.66GHz):
> 41.61s user 3.71s system 99% cpu 45.530 total
> 
> However, testing whether there is something new to merge could be
> performed significantly faster:
> 
> $ time sh -c 'for ((i=0; i<140; i++)); do [ -n "$(git rev-list --max-count=1 v2.6.26 ^HEAD)" ]; done'
> sh -c   5.49s user 0.26s system 99% cpu 5.786 total
> 
> The same loop with "git merge-base v2.6.26 HEAD" takes about 40 
> seconds here - apparently finding the merge base is the expensive 
> part, and it makes sense to avoid it if you expect that most of your 
> branches do not contain anything new to merge.

using git-fastmerge i get 2.4 seconds:

  $ time for ((i=0; i<140; i++)); do git-fastmerge v2.6.26; done
  [...]
  real    0m2.388s
  user    0m1.211s
  sys     0m1.131s

for something that 'progresses' in a forward manner (which merges do fundamentally) nothing beats the performance of a timestamped cache i think.

at least for my usecase.

Even assuming that the filesystem is sane, is my merge-cache implementation semantically equivalent to a git-merge? One detail is that i suspect it is not equivalent in the git-merge --no-ff case. (but that is a not too interesting non-default case anyway)

	Ingo