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

Michael J Gruber [off-list ref] writes:

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