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

From: Will Palmer <wmpalmer@gmail.com>
Date: Jul 6, 2010, 15:31 UTC
Message-ID: <1278430303.32094.15.camel@wpalmer.simply-domain>
In-Reply-To: <20100706115826.GA15413@sigill.intra.peff.net>

On Tue, 2010-07-06 at 07:58 -0400, Jeff King wrote:

Show 14 quoted lines

> On Mon, Jul 05, 2010 at 10:10:12AM -0400, tytso@mit.edu wrote:
> > I'm not sure this is a good tradeoff, but given in practice how rarely
> > most developers go back in time more than say, 12-24 months, maybe
> > it's worth doing.  What do you think?
> 
> I'm not sure. I am tempted to just default it to 86400 and go no
> further.  People who care about archaeology can turn off traversal
> cutoffs if they like, and as the skewed history ages, people get less
> likely to look at it. We could also pick half a year or some high number
> as the default allowable. The performance increase is still quite
> noticeable there, and it covers the only large skew we know about. I'd
> be curious to see if other projects have skew, and how much.
> 
> -Peff

Is it wrong to expect that git perform poorly in the edge-cases (hugely skewed timestamps), but that it perform /correctly/ in all cases?

Clearly, marking already-traversed histories was the right thing to do, and if I read correctly, made a good improvement on its own. But you seem to have crossed a line at some point between "optimization" and "potentially giving the wrong answer because it's faster"

Or am I just misunderstanding here?