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

From: Junio C Hamano <gitster@pobox.com>
Date: May 4, 2011, 15:36 UTC
Message-ID: <7vpqnyfpey.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4DC0F845.2080903@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

Show 6 quoted lines

>> 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 "..".