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

Jeff King [off-list ref] writes:

On Wed, Aug 22, 2012 at 03:59:43PM -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>

Hmm, for some reason I had no recollection of the original thread at
all. And yet reading the archives, I apparently had quite a bit to say.
Reading again with fresh eyes, I still think this is sane.

I don't think assigning any revision magic to ".." besides "the empty
range" makes sense at all for the reasons you gave in the original
thread. And the empty range is a pointless no-op. So I don't see any
real argument in favor of disambiguating towards the revision.

I don't think that ".." is really a no-op.  It is true that HEAD..HEAD
does not itself result in any revisions, but it *could* be used as a
silly shorthand to introduce ^HEAD into the objects being walked.  This
can make a difference if it then excludes other objects, too.

I would argue that such use is misguided, and I am in favor of the
patch, but in theory it is possible.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch