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

From: Jeff King <peff@peff.net>
Date: May 2, 2011, 21:01 UTC
Message-ID: <20110502210141.GA15753@sigill.intra.peff.net>
In-Reply-To: <7v62pslt2k.fsf_-_@alter.siamese.dyndns.org>

On Mon, May 02, 2011 at 01:56:51PM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> 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@peff.net>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Looks good to me.

Doing "..." is still allowed, but will never produce any useful results. I don't know if it is worth disallowing it to catch errors. I am tempted to say it should be magic for "@{u}...HEAD", but I think just "..." is getting unreadably magical. "@{u}...HEAD" is already pretty concise and is much more readable.

-Peff