On Tue, 2010-07-06 at 07:58 -0400, Jeff King wrote: > On Mon, Jul 05, 2010 at 10:10:12AM -0400, tytso@xxxxxxx 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html