@@ -100,9 +100,22 @@ to point at the new commit.
100
100
101
101
[[def_detached_HEAD]]detached HEAD::
102
102
Normally the <<def_HEAD,HEAD>> stores the name of a
103
- <<def_branch,branch>>. However, Git also allows you to <<def_checkout,check out>>
104
- an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any
105
- particular branch. In this case HEAD is said to be "detached".
103
+ <<def_branch,branch>>, and commands that operate on the
104
+ history HEAD represents operate on the history leading to the
105
+ tip of the branch the HEAD points at. However, Git also
106
+ allows you to <<def_checkout,check out>> an arbitrary
107
+ <<def_commit,commit>> that isn't necessarily the tip of any
108
+ particular branch. The HEAD in such a state is called
109
+ "detached".
110
+ +
111
+ Note that commands that operate on the history of the current branch
112
+ (e.g. `git commit` to build a new history on top of it) still work
113
+ while the HEAD is detached. They update the HEAD to point at the tip
114
+ of the updated history without affecting any branch. Commands that
115
+ update or inquire information _about_ the current branch (e.g. `git
116
+ branch --set-upstream-to` that sets what remote tracking branch the
117
+ current branch integrates with) obviously do not work, as there is no
118
+ (real) current branch to ask about in this state.
106
119
107
120
[[def_dircache]]dircache::
108
121
You are *waaaaay* behind. See <<def_index,index>>.
0 commit comments