Re: [RFC/PATCHv2 6/6] limit "contains" traversals based on commit generation
- From
Jeff King <peff@peff.net>
- Date
- Jul 13, 2011, 21:18 UTC
- Message-ID
- <20110713211826.GA17284@sigill.intra.peff.net>
- In-Reply-To
- <7vpqld6g14.fsf@alter.siamese.dyndns.org>
On Wed, Jul 13, 2011 at 02:12:55PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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).
Yes, the slop code in still_interesting could use a "timestamp_is_bogus(commit)" check. It could also use generation numbers. :)
I actually wonder if we could make merge-base computation more efficient using generation numbers, and if it would be worth switching more algorithms over to it. I haven't thought too hard about it, though.
-Peff