From: Junio C Hamano Date: Wed, 13 Jul 2011 21:12:55 GMT Subject: Re: [RFC/PATCHv2 6/6] limit "contains" traversals based on commit generation Message-ID: <7vpqld6g14.fsf@alter.siamese.dyndns.org> In-Reply-To: <20110713205844.GA15435@sigill.intra.peff.net> Jeff King writes: > Or are you suggesting dropping generations entirely, and just using > marked-up commit timestamps (or even a flag saying "this timestamp is > bogus, don't use it for cutoffs")? Not suggesting, but that was exactly what I was wondering. For example, still_interesting() in revision.c says "compare timestamp and return SLOP, not 'we are done'", and presumably that code could notice that "ah, this commit is marked as being on a stretch that timestamp based cut-off is unusable--keep digging". The "tag --contains" and "name-rev" would also have similar logic (I haven't looked at them for a while though). > But there's a big question of deciding which timestamps are bogus. I agree that the ones that you need to dig through may not be the ones with bogus timestamps, but either an ancestor or a descendant (I haven't thought it through) of a commit with bogus timestamp. That is why I said "a commit on a stretch that timestamp based cut-off is unusable". > But I think I still like generation numbers because: > > 1. They're simple, complete, and unambiguous. No question nor dispute about it. > The only slowness for the generation slowness is the > extra I/O on writing out the cache. But it's not very much,... Ok.