On Wed, Jul 13, 2011 at 02:12:55PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 -- 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