From: "Junio C Hamano" <gitster@xxxxxxxxx> : Saturday, July 02, 2016 12:01
AM
Junio C Hamano <gitster@xxxxxxxxx> writes:
On Fri, Jul 1, 2016 at 3:08 PM, Philip Oakley <philipoakley@xxxxxxx>
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
--
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