In the code we literally stick "refs/heads/" on the front
and see if it resolves, so that is probably the best
explanation.
Signed-off-by: Jeff King <peff@xxxxxxxx>
---
I hope this helps a little bit with Mark's confusion. But while writing
it, I really think it would be a simpler rule to say "if it's in
refs/heads/, then it's a branch" (which is similar to what Mark
suggested earlier).
So "git checkout refs/heads/master" would be identical to "git checkout
master". That would require a code change, though.
Documentation/git-checkout.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 4a1fb53..ad4b31e 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -114,11 +114,11 @@ the conflicted merge in the specified paths.
"merge" style, shows the original contents).
<branch>::
- Branch to checkout (when no paths are given); may be any object
- ID that resolves to a commit. Defaults to HEAD.
-+
-When this parameter names a non-branch (but still a valid commit object),
-your HEAD becomes 'detached'.
+ Branch to checkout; if it refers to a branch (i.e., a name that,
+ when prepended with "refs/heads/", is a valid ref), then that
+ branch is checked out. Otherwise, if it refers to a valid
+ commit, your HEAD becomes "detached" and you are no longer on
+ any branch (see below for details).
+
As a special case, the `"@\{-N\}"` syntax for the N-th last branch
checks out the branch (instead of detaching). You may also specify
--
1.6.3.rc0.148.g141203.dirty
--
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