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.
Attachment:
pgphwpKNfnFi3.pgp
Description: PGP signature
