Jeff King <peff@xxxxxxxx> writes: >> Thanks; I was wondering about this myself but you bisected it faster. >> >> Will revert. > > One other thing I noticed during the bisect: when using a version of git > containing 83c9031, the merge took a lot longer. As in, 13 seconds with > v1.7.3 versus 69 seconds with master. > > That may simply be because the bug being demonstrated causes us to > erroneously do more file-level merging than we would otherwise need to. Yeah, the reverted 83c9031 (unpack_trees(): skip trees that are the same in all input, 2010-12-22) also seems to have seriously broken intermediate merge merge-recursive makes. I actually recall scratching my head when I made 00e6ee7 (Merge branch 'maint', 2011-02-11) that was causing add/add conflict when it shouldn't. It turns out that quite a lot of entries were missing in contrib/ area from the virtual common ancestry tree synthesized by merge-recursive that called into the botched unpack_trees()---it of course would result in add/add conflict if a merge is done using such a tree as the common. No, I haven't had a chance nor energy to dig further than what I reported above. -- 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