Re: git-name-rev off-by-one bug

From: Junio C Hamano <junkio@cox.net>
Date: Dec 1, 2005, 07:46 UTC
Message-ID: <7vu0dtl0o3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0511301707020.25300@iabervon.org>

Delight in working on free software project is you have so many good people with you that you can have many "Aha, lightbulb!" moments. This is one of them for me. I realized where the trouble I felt when reading your table came from; it was that I was focused on the old way the table was organized too much.

When one constructs a case table to make sure one covered everything, one first lists the variables and the possible values they can take, and make NxMxOxPx... grid. In the original table I did, I chose what is in O and A and B as my variables (and that's where my comment about O being bit2 etc comes from). I did not realize the semantics and algorithm you used can be better described by different set of variables (namely, how ancestors match the HEAD, and how the remote matches the HEAD, if I understand correctly). I had trouble understanding your version only because I kept thinking in terms of (O,A,B).

So after thinking about that...

    Daniel Barkalow <barkalow@iabervon.org> writes:

    > On Wed, 30 Nov 2005, Junio C Hamano wrote:
    >
    > Perhaps the table would be clearer if the lines were grouped
    > in exists/missing? (With 5ALT repeated in the 011 and 111
    > groups, since it applies to both) Then you would only need
    > to look at 5 lines with cascading (in the most complex
    > case), rather than having to read the whole top of the
    > table.

I think the current ordering of cases makes more sense. If we forget about the case labels from the original table (and the way the original table classified cases), I suspect we could reorganize the cases to describe the semantics even better and clearer. That is, not grouping by exists/missing, but grouping by matching/unmatching.

> (It is actually written like that, with the exception of 5ALT, 2ALT, and 
> 3ALT, but it's not visually obvious.)

Yeah, I now realize that.

Show 8 quoted lines

> The tricky bit is really cases 2ALT and 3ALT, which can be used in cases 
> where some but not all of the ancestors are empty, and can't be used if 
> there's a directory/file conflict; neither of these conditions matters for 
> anything else in the table, so it's hard to fit this in. My strategy is to 
> have those as special cases, and have the rest of the table cover 
> everything (rather than having case 2 require a directory/file conflict 
> and case 7 require that no ancestor be empty, which would be accurate, but 
> would make it harder to check for missing cases).

Makes sense.  Thanks for the clarification and lightbulb moment.