On Sun, Jul 06, 2008 at 03:33:16PM -0700, Junio C Hamano wrote:
> Dmitry Potapov <dpotapov@xxxxxxxxx> 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
--
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
