Rene Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes: > Don't care if objects have been parsed or not and don't stop when we > reach a commit that is already clean -- its parents could be dirty. There is something quite wrong with this patch. When you are dealing with complex commit ancestry, this ends up traversing the same parent over and over again. I tried to do a merge in linux-2.6 history with these two commits: v2.6.17-g29454dd v2.6.17-gd6b0c53 The former is Linus's head at this writing, and the latter is James Bottomley's scsi-misc head. git describe 29454dd d6b0c53 from the "master" branch returns immediately (the use there can assume that the mark is set and contiguous, I think) while the one with this patch takes forever. Another example is to try changing get_merge_bases() to always clean-up as Johannes had originally and try computing the merge base between the two. Just before it starts to clean-up, it has only seen 5983 objects (object.c::nr_objs) and it definitely would be faster to clean flags from all these objects than to wait for the two calls to clear_commit_marks() to complete, which seems to also take forever. - : 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