Re: What's cooking in git.git (Jul 2010, #05; Wed, 28)

From: Jeff King <peff@peff.net>
Date: Jul 30, 2010, 18:37 UTC
Message-ID: <20100730183709.GC18544@coredump.intra.peff.net>
In-Reply-To: <7vvd7zuecv.fsf@alter.siamese.dyndns.org>

On Wed, Jul 28, 2010 at 09:00:16PM -0700, Junio C Hamano wrote:

Show 8 quoted lines

> --------------------------------------------------
> [Stalled -- would discard unless there are some movements soon]
> [...]
> * 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

What do we want to do with this?

The first patch by itself produces a pretty big speedup for Ted's case, and does not impact correctness. However, it does do a mindless depth-first search, so there are cases where it can be slower than the current code (basically, if you never have to go to the roots for your tagset, then my code will be slower, as it will almost certainly go to the roots, but it will do so only one time for the whole set, instead of potentially once per tag).

The second patch by itself is harmless, as the user has to turn it on explicitly. And the amount of code is quite small, so even if most people don't use it, I don't think it is a problem.

The third one is where we start defaulting things to "assume no more than 1 day of clock skew by default", which can cause incorrect answers in the face of skew.

The fourth is just an illustrative patch for per-repo skew detection.

So if the tradeoff for patch 1 is acceptable, we can merge the first two. If the tradeoff in patch 3 is acceptable, then we can merge up to patch 3. The fourth one should be thrown out either way. I can work up a "detect clock skew on clone and gc" patch based on it if we want to go that way.

-Peff