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.