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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 02, 2011 at 12:15:23PM -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 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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]