Junio C Hamano venit, vidit, dixit 03.05.2011 19:38:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>
>>>> Helped-by: Jeff King <peff@xxxxxxxx>
>>>> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
>>>
>>> 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
--
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