From: Thomas Rast Date: Thu, 23 Aug 2012 11:56:52 GMT Subject: Re: [PATCH] specifying ranges: we did not mean to make ".." an empty set Message-ID: <874nntq0sb.fsf@thomas.inf.ethz.ch> In-Reply-To: <20120823082916.GA6963@sigill.intra.peff.net> Jeff King writes: > On Wed, Aug 22, 2012 at 03:59:43PM -0700, Junio C Hamano wrote: > >> 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 >> Signed-off-by: Junio C Hamano > > 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