Re: git describe --contains doesn't work properly for a commit

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
>
>
>> This one, and $gmane/264101, are a few instances of this known issue
>> raised here recently.
>
> If $gmane/264101 is caused by clock skew, I'd find that disturbing.
> Those algorithms are supposed to be "correct, but slower" in the face of
> skew, not ever incorrect.

My understanding is that the commit painting done by merge-base is
designed to be always correct, but the A..B revision traversal
depends on SLOP being big enough.  When the traversal queue is
filled with all UNINTERESTING commits, some of which needs to be dug
to reveal newer commits that are not yet painted as UNINTERESTING in
order to get the complete picture, the still_interesting() logic
will end up stopping prematurely, leaving commits that are actually
UNINTERESTING in the topological sense unpainted in the resulting
newlist that is assigned to revs->commits in limit_list(), yielding
an incorrect result.

>> > Calculating them is simple. Caching and storage is the bigger question.
>> 
>> Yes, also having to handle the ones whose generation numbers haven't
>> been computed yet adds to the complexity.
>
> I'm not sure it's that bad. If you cache generation numbers for all
> known commits when you repack, then worst case you have to traverse all
> commits not in the pack.
> ...
> IMHO, if you are going to go to the trouble to detect and store skew,
> you should just go to the trouble to calculate and store reliable
> generation numbers.

I would actually prefer a solution with generation numbers, of
course, because that would give us provably correct result.  If it
can be done without too much hassle, I am all for it.  Scrap the
half-baked "I've been wondering" compromise ;-)

Thanks.