On Tue, Nov 09, 2010 at 11:53:19AM -0800, Junio C Hamano wrote: > * jk/tag-contains (2010-07-05) 4 commits > - Why is "git tag --contains" so slow? > - default core.clockskew variable to one day > - limit "contains" traversals based on commit timestamp > - tag: speed up --contains calculation > > The idea of the bottom one is probably Ok, except that the use of object > flags needs to be rethought, or at least the helper needs to be moved to > builtin/tag.c to make it clear that it should not be used outside the > current usage context. This, btw, is still on my todo list. I got pleasing performance results using a notes tree to store a list of commits with bogus timestamps, so I need to clean that up and submit. I think that may spin off into its own topic entirely, as it is about handling clock skew better everywhere, not just in the newly introduced "tag --contains" code. I'm also still trying to figure out if there is a way to avoid the depth-first search of the "tag --contains" patch. It can have worse performance in a few corner cases than the merge-base approach (i.e., we end up going to the roots sometimes when we make an unlucky depth-first traversal). Though with the commit-time optimization (which depends on sane skew handling from above), that goes away, so maybe it is not worth caring too much. -Peff -- 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