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

[Jeff King <peff@peff.net>]

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

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