Re: What's cooking in git.git (Nov 2010, #01; Tue, 9)

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