Re: [RFC/PATCHv2 6/6] limit "contains" traversals based on commit generation

Jeff King [off-list ref] 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.

On Wed, Jul 13, 2011 at 02:12:55PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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