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

Junio C Hamano venit, vidit, dixit 03.05.2011 19:38:

Michael J Gruber [off-list ref] writes:

quoted

quoted

quoted

Helped-by: Jeff King [off-list ref]
Signed-off-by: Junio C Hamano <redacted>

Looks good to me.

I'm sorry but I don't like this at all, because:

quoted

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