Re: [PATCH v2] specifying ranges: we did not mean to make ".." an empty set

Michael J Gruber [off-list ref] writes:

quoted

Contrast that with ".." and realize that is very different.  It is
infinitely more likely that the user meant the immediate parent directory
than an empty revision range.

and that is a straw man argument. I suggested "@{u}..HEAD" for "..",
because I consider that much more useful.

But the thing is, 

Either of @{u}.. or ..@{u} may be an often used range depending on who you
are and what you want to find.  But reusing ".." for that purpose would be
a very steep uphill battle for obvious reasons that I can count at least
three:

 * How can a user remember ".." stands for whichever of @{u}.. or ..@{u}
   you happen to pick?

 * Can you guarantee that there will never be anything _more_ common and
   useful than "@{u}.." that deserves to use ".." as a shorthand?  I
   can't.

 * Doing anything other than an empty range for ".." is a bit _too_
   magical for my taste.  After all, if $A.. means $A..HEAD and ..$B means
   HEAD..$B, giving an empty string to $A or $B should yield nothing other
   than HEAD..HEAD, unless you want to confuse the user.

I think your argument is that I wouldn't have felt the annoyance if ".."
meant a vastly more useful range that is totally different from the
current semantics, because I would have understood that ".." could be both
a useful range and a useful pathspec, and there won't be "Stipid git!  I
know .. could be an empty range but it should be obvious to you that I
didn't mean that interpretation with no practical value. Just take it as a
parent directory pathspec!".

You could achieve that by time-travelling to a past where no git user were
present and inplement "$A..$B" to default in that way from day one, and if
I were living in such a world, I would certainly agree with you.

But that is not the world we live in.

In other words, both of us agree with the statement: "What .. means today
has no practical value".  But I do not think that the conclusion that
follows that statement should be "so let's change its semantics and make
it do something useful".  Changing it to anything magical breaks
consistency in a big way, than keeping this degerated case as such.

As I said in the beginning of the thread, this was a mere annoyance, and I
wouldn't be unhappy to drop this change.  I will have to type "../" myself
when I mean "parent directory", but that is a minor annoyance.  But it
also may turn out to be a disaster that everybody else needs to teach new
people to do so.

As to changing the semantics of "..", I am moderately against it, but I
consider that is a separate topic.  I am not opposed to giving a range
that is common and useful (be it @{u}.., ..@{u}, or anything else) a
short-hand, but that short-hand should not be "..".