Junio C Hamano <gitster@xxxxxxxxx> writes:
> As to changing the semantics of "..", I am moderately against it, but I
> consider that is a separate topic. I am not opposed to giving a range
> that is common and useful (be it @{u}.., ..@{u}, or anything else) a
> short-hand, but that short-hand should not be "..".
After re-reading 1654a46 (specifying ranges: we did not mean to make ".."
an empty set, 2011-05-02), I found that I was contradicting myself in the
patch.
The last part of the documantation update in that patch is clearly wrong.
The patch does not change what ".." means. The only thing it does is to
widen the heuristics that is used to disambiguate when the input could be
ambiguous.
Documentation/revisions.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index fd043f7..80e5a47 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -187,10 +187,10 @@ It is the set of commits that are reachable from either one of
In these two shorthands, you can omit one end and let it default to HEAD.
For example, 'origin..' is a shorthand for 'origin..HEAD' and asks "What
did I do since I forked from the origin branch?" Similarly, '..origin'
is a shorthand for 'HEAD..origin' and asks "What did the origin do since
-I forked from them?" Note that you cannot omit both ends. '..' is not
-an empty range that is both reachable and unreachable from HEAD.
+I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an
+empty range that is both reachable and unreachable from HEAD.
Two other shorthands for naming a set that is formed by a commit
and its parent commits exist. The `r1{caret}@` notation means all
parents of `r1`. `r1{caret}!` includes commit `r1` but excludes
--
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