Jeff King <peff@xxxxxxxx> writes: > On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote: > >> with current trunk I get the following on an up-to-date Linux tree: >> >> markus@x4 linux % time git pull >> Already up-to-date. >> git pull 7.84s user 0.26s system 92% cpu 8.743 total >> >> git version 1.7.12 is much quicker: >> >> markus@x4 linux % time git pull >> Already up-to-date. >> git pull 0.10s user 0.02s system 16% cpu 0.740 total > > Yikes. I can easily reproduce here. Bisecting between master and > v1.7.12 gives a curious result: the slowdown first occurs with the merge > commit 34f5130 (Merge branch 'jc/merge-bases', 2012-09-11). But neither > of its parents is slow. I don't see anything obviously suspect in the > merge, though. There is one extra call site of reduce_heads() added by that merge relative to 34f5130. It is likely that the updated reduce_heads() is totally broken from performance point of view, or at least it is not optimized for the usage pattern at the new call site, in which case it would be very plausible that both parents of the merge perform well while the merge result is sucky. It gets more curious, though. I am getting ~9 seconds with the tip of master and ~0.4 seconds with 1.7.12. When 34f5130^2 is reverted at the tip of master, I get ~0.35 seconds. That matches Markus's observation. However. If I revert 5802f81 that updated the implementation of fmt-merge-msg on top of 'master', *without* reverting 34f5130^2, I get ~4.5 seconds. As we are doing an "Already up-to-date" pull, I thought there is no need to call fmt-merge-msg in the first place? Which may indicate that "git merge" has been broken for a long time and making unnecessary calls. Hrmmm... -- 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