Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > In this particular case, I cannot help but notice that commits performed > on a detached HEAD will get lost _unless_ they are somehow put onto a > named branch eventually. So the only question is whether you restrict > flexibility by requiring to name the branch first before committing, > instead of committing and then naming the branch. You are forgetting another important case. You may not even want to keep what you will be committing to the throw-away temporary state. That is why I liked the proposal by James to introduce a third state (i.e. not on local branch, but cannot commit) at the conceptual level, even though as Daniel pointed out and Nico and I concurred later, the implementation may need to be based on the detached HEAD to avoid "git fetch" surprises. You can of course fix it in different ways. The third state could be implemented by pointing at a non local branch ref with HEAD, and then by making fetch refuse to update, just like we refuse a push from side to make the working tree state inconsistent. Either way, confusion arising from accidental (or unintended) detaching would be removed for new users, and that won't have to harm people who need to (because they _are_ used to) be able to work on detached HEAD, no? -- 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