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

Jeff King venit, vidit, dixit 02.05.2011 23:01:

On Mon, May 02, 2011 at 01:56:51PM -0700, Junio C Hamano wrote:

quoted

Either end of revision range operator can be omitted to default to HEAD,
as in "origin.." (what did I do since I forked) or "..origin" (what did
they do since I forked).  But the current parser interprets ".."  as an
empty range "HEAD..HEAD", and worse yet, because ".." does exist on the
filesystem, we get this annoying output:

  $ cd Documentation/howto
  $ git log .. ;# give me recent commits that touch Documentation/ area.
  fatal: ambiguous argument '..': both revision and filename
  Use '--' to separate filenames from revisions

Surely we could say "git log ../" or even "git log -- .." to disambiguate,
but we shouldn't have to.

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:

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.

For "..", we should either catch the error or, better, have ".." default
to "@{u}..HEAD" and do the same for "...". Those are used much more
often, and this goes with "try to parse as a rev first, then pathspec".

Michael