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). > 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. -- 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