Jeff King <peff@xxxxxxxx> 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 <peff@xxxxxxxx>
>> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html