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

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 03.05.2011 19:38:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>>>> 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

I care about:

- sane defaults
- sane arguments

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

and that is a straw man argument. I suggested "@{u}..HEAD" for "..",
because I consider that much more useful. "Infinitely more likely" is
obviously true and obviously pointless when you compare with something
of zero likelihood (and nonsense otherwise). I have no problem accepting
a majority vote or sane arguments, but not something like this, sorry.

Michael