Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>> 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 "..".
--
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