Re: Why is "git tag --contains" so slow?

From: Jeff King <peff@peff.net>
Date: Jul 8, 2010, 11:28 UTC
Message-ID: <20100708112802.GA2294@sigill.intra.peff.net>
In-Reply-To: <20100706165336.GJ25518@thunk.org>

On Tue, Jul 06, 2010 at 12:53:36PM -0400, tytso@mit.edu wrote:

Show 13 quoted lines

> We would be much better off if our tools enforced the fact that
> committer times were always increasing.  If from the beginning, we had
> introduced checks so that "git commit" refused to create new commits
> where the committer time was before its parent commit(s), and
> git-receive-pack refused to accept packs that contained
> non-monotonically increasing commits or commits that occurred in the
> future according to its system clock, then these optimizations would
> be completely valid.
> 
> But we didn't, and we do have skew in some repositories.  So the
> question is what to do going forward?  One solution might be to
> enforce this moving forward, and to have varying levels of strictness
> in enforcing this constraint.  So for completely new repositories,

Whatever we do with the optimization, I do agree with your suggestion at least for "git commit" to avoid making such commits. Rejecting them during fetchs and pushes would be a nice, too, but should probably just be a warning at first, in case you have to pull from somebody with an older git. You would also have to consider whether some small skew is acceptable during a pull. Something like a 5-second skew is not a big deal. If you had thousands of such skews in a row, yes, it would be bad, but that is not likely to happen (and I can't think of some way to maliciously create such a history that would not otherwise be unusable).

> this becomes a non-brainer.  For older repositories, Jeff's idea of
> having a tunable parameter so that results are correct given a maximum
> clock skew --- which can be determined --- will allow us to have
> correctness _and_ performance.

Yeah. I think the real question is what the default for that parameter should be: pessimistic but always correct, optimistic but possibly incorrect in the face of skew, or auto-tuned per-repository.

-Peff