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