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

From: Junio C Hamano <gitster@pobox.com>
Date: May 3, 2011, 17:38 UTC
Message-ID: <7vvcxrit07.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4DBFA31E.40207@drmicha.warpmail.net>

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

Show 17 quoted lines

>>> Helped-by: Jeff King <peff@peff.net>
>>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>> 
>> Looks good to me.
>
> I'm sorry but I don't like this at all, because:
>
>> Doing "..." is still allowed, but will never produce any useful results.
>> I don't know if it is worth disallowing it to catch errors. I am tempted
>> to say it should be magic for "@{u}...HEAD", but I think just "..." is
>> getting unreadably magical. "@{u}...HEAD" is already pretty concise and
>> is much more readable.
>
> We need to disambiguate any pathspec with "--" which could be a revision
> parameter. Therefore I find it very unnatural to disambiguate ".." to a
> pathspec automatically (and have "..." error out). "../" is really
> simple enough to type.

If you are comfortable typing "../", why do you even care? It would be a different story if the patch made ".." error out and forbade to be used as an empty range even when you disambiguated, i.e. "git log .. --", but that is not what we are doing.

And we do not even special case "...". Between the two potential requests of asking for an empty revision range and asking for a pathspec "...", both are just as unlikely.

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.