Dmitry Potapov <dpotapov@xxxxxxxxx> writes:
> On Sun, Jul 06, 2008 at 01:04:18PM -0700, Junio C Hamano wrote:
>> Two other shorthands for naming a set that is formed by a commit
>> and its parent commits exists. `r1{caret}@` notation means all
>> parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
>> its all parents.
>
> So, I would say that rev^! is shorthand for rev^@..rev, but it does not
> actually work:
>
> 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.
But perhaps these paragraphs need to be further reworded to avoid the
confusion. I dunno.
--
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
