Re: [RFC/PATCHv2 6/6] limit "contains" traversals based on commit generation
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 13, 2011, 21:12 UTC
- Message-ID
- <7vpqld6g14.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110713205844.GA15435@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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.