Re: [PATCH v2 4/4] doc: clarify that `^r1` will exclude `r1` itself

["Philip Oakley" <philipoakley@iee.org>]

From: "Junio C Hamano" <gitster@pobox.com> : Saturday, July 02, 2016 12:01 
AM
> Junio C Hamano <gitster@pobox.com> writes:
>
>> On Fri, Jul 1, 2016 at 3:08 PM, Philip Oakley <philipoakley@iee.org> 
>> wrote:
>>>>>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>  To exclude commits reachable from a commit, a prefix '{caret}'
>>>>>  notation is used.  E.g. '{caret}r1 r2' means commits reachable
>>>>> -from 'r2' but exclude the ones reachable from 'r1'.
>>>>> +from 'r2' but exclude 'r1' and those reachable from 'r1'.
Hi Junio
Sorry for the delay in response, I'd been away and had some catch up to do.

I think we may have dropped into a YXproblem.

My particular concern was the literary conflict between the implicit 
'inclusive' aspects and the explicit 'exclusive' parts of the descriptions, 
a sort of barber shaving problem [1], especially when used in conjunction 
with the negation.

It's the potential for reader confusion at that point (particularly for a 
string of pearls case) I was trying to address. However, you are right that 
'reachable' also isn't as well defined as it might be.

For example, in a DAG, we should have no cycles where directed edges lead 
can back to their start point, yet (for reachability discussions) we want to 
imply an extra loopback edge, all of which is part of the sloppiness of 
natural languages.

This potential for confusion is further shown in the summary where both 
<rev> and ^<rev> say "(i.e. ancestors of)"!

In summary, I think that both the definition of reachability needs 
clarifying, and that c0ffee..deadbeef excludes any serving of c0ffee, even 
for a line of pearls, should be covered.

>>>>
>>>> Well, if you have to spell that out, you'd want to spell out r2 side
>>>> too, no?  That is,
>>>
>>> The clarification wasn't about what "reachable" means but about 
>>> inclusivity,
>>> such as whether 0..4 would give 0,1,2,3,4 or would be 'off by one' and 
>>> only
>>> give 1,2,3,4. And in this case it's the latter.
>>
>> Well, you have the same inclusivity issue on the opposite end, no? Is 
>> 0..4
>> a range with 0,1,2,3,4? 0,1,2,3? 1,2,3,4? or 1,2,3?

In most natural language we have 0:4 is 0,1,2,3,4 so the exclusion of 0 
would be the one to note.

>>
>>> Describing 'reachability' is a whole different kettle of fish, as you
>>> highlight below, and would be separate from this patch.
see below.

>>
>> I am not sure I agree. It all is about "is the endpoint included or 
>> not?".
>
> This did not come out as illustrating as I hoped.  Let's put it
> differently.
>
> I think this is all about how "reachable" is defined.  "Am I an
> ancestor of myself?" is the question.

I don't think that just clarifying "reachability" would be sufficient. 
Necessary yes, sufficient no.

>
> If "all commits reachable from r1" includes 'r1', then, it is clear
> that "... but exclude those reachable from 'r1'" means 'r1' is not
> part of the resulting set.
>
> If I were not an ancestor of me, on the other hand, "... but exclude
> those who are ancestors of 'r1'" would not exclude 'r1'.  If 'r1' is
> reachable from 'r2', then 'r1' would be in the resulting set.
>
> The same thing happens at the opposite end of the "range".  If I am
> an ancestor of me, then "all commits reachable from 'r2'" does
> inculde 'r2'; if I am not an ancestor of me, 'r2' is not part of the
> resulting set.
>

> Note.
> I said "range" in quotes, because this is not like
> drawing a straight line and placing two points to denote the
> lower and the upper bounds of the "range".  What Git does is
> a set operation, "r2 ^r1" excludes what is reachable from r1
>        from the set of commits that are reachable from r2.

The understanding of this "Y" branching "range" is the part that was the 
'whole new kettle of fish' for me, especially with the rtbs, that caught me 
out during early contributions.


>
> By choosing the definition of "reachable" consistently, 0..4 can
> mean either 1,2,3,4 (I am reachable from myself) or 0,1,2,3 (I can
> not be reached by me), and in order to clarify that we give 1,2,3,4
> and not 0,1,2,3, we still need to clearly define what "reachable"
> means.

I'll re-think the patch (4/4) to cover thse issue.

>
> But any other interpretation, e.g. 0,1,2,3,4, is incoherent.
> --
Philip

[1] https://en.wikipedia.org/wiki/Barber_paradox