Re: [Annoyance] "git log .." thinks ".." is ambiguous

From: Jeff King <peff@peff.net>
Date: May 2, 2011, 19:33 UTC
Message-ID: <20110502193321.GB10487@sigill.intra.peff.net>
In-Reply-To: <7vr58glxro.fsf@alter.siamese.dyndns.org>

On Mon, May 02, 2011 at 12:15:23PM -0700, Junio C Hamano wrote:

Show 12 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 this resulted in ".." to be interpreted
> 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 .. --", but we shouldn't have to.

I got slightly confused reading this, because I thought at first you wanted ".." to be some kind of magic rev specifier. In particular, your last line should say:

  git log -- ..

no?

I finally figured it out by reading your example carefully.

As far as the patch goes, I think it is the right thing to do. We should probably disallow ".." as a revision (because it is nonsensical to ask for, just as it would be to ask for a non-existent ref). And then the only sane thing is to consider it as a path.

I didn't check, but what does your patch do with:

  $ cd "`git rev-parse --show-toplevel`"
  $ git log ..

-Peff