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

* Sergey Vlasov [off-list ref] wrote:

On Wed, 23 Jul 2008 15:05:18 +0200 Ingo Molnar wrote:

quoted

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