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

From: Jeff King <peff@peff.net>
Date: Nov 9, 2010, 22:11 UTC
Message-ID: <20101109221142.GB5617@sigill.intra.peff.net>
In-Reply-To: <7vbp5ymfyo.fsf@alter.siamese.dyndns.org>

On Tue, Nov 09, 2010 at 11:53:19AM -0800, Junio C Hamano wrote:

Show 10 quoted lines

> * 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