Re: [q] git-diff --reverse 7def2be1..7def2be1^

From: Dmitry Potapov <dpotapov@gmail.com>
Date: Jul 7, 2008, 04:01 UTC
Message-ID: <20080707040131.GC1721@dpotapov.dyndns.org>
In-Reply-To: <7vbq1ad4nn.fsf@gitster.siamese.dyndns.org>

On Sun, Jul 06, 2008 at 03:33:16PM -0700, Junio C Hamano wrote:

Show 37 quoted lines

> Dmitry Potapov <dpotapov@gmail.com> writes:
> 
> > git rev-list 7ac749c^@..7ac749c
> > fatal: ambiguous argument '7ac749c^@..7ac749c': unknown revision or path
> > not in the working tree.
> >
> > yet "^rev^@ rev" syntax does:
> >
> > git rev-list ^7ac749c^@ 7ac749c
> > 7ac749c96d143ba4f76723959892cbaddbe8ed07
> >
> > Is it a bug or feature?
> >
> > Puzzled...
> 
> After reading these paragraphs from "SPECIFYING RANGES":
> 
>         History traversing commands such as 'git-log' operate on a set
>         of commits, not just a single commit.  To these commands,
>         specifying a single revision with the notation described in the
>         previous section means the set of commits reachable from that
>         commit, following the commit ancestry chain.
> 
>         To exclude commits reachable from a commit, a prefix `{caret}`
>         notation is used.  E.g. "`{caret}r1 r2`" means commits reachable
>         from `r2` but exclude the ones reachable from `r1`.
> 
>         This set operation appears so often that there is a shorthand
>         for it.  "`r1..r2`" is equivalent to "`{caret}r1 r2`".  It is
>         the difference of two sets (subtract the set of commits
>         reachable from `r1` from the set of commits reachable from
>         `r2`).
> 
> it is obvious to me that the third paragraph talks about r1 that is a
> single rev (refer to SPECIFYING REVISIONS section, which does _NOT_ talk
> about rev^@ nor rev^!)  and r2 that similarly is another single rev.  So I
> think it is fairly clear that your "r^@..r" example is nonsense.

I think both second and third paragraphs talk about r1 as a single revision. Yet, it is allowed to use "^r^@ r", and it works fine while you cannot use "r^@..r". Of course, this behavior does not contradict documentation, as it says _nothing_ about what will happen if you use "r^@" instead of r1. That is why asked whether it is a bug or feature. It still escapes me though, why you consider "r^@..r" as nonsense while "^r^@ r" as correct syntax. Not that I am trying to argue with how it should work, but I am just trying to understand your logic here.

Dmitry