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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to