Nicolas Pitre <nico@xxxxxxxxxxx> writes: > It is indeed simpler. It makes the checkout command less verbose as > well. Only the commit command would need to warn the user and only if a > forbidden operation is attempted (like committing on a non > refs/heads/*). I think I like this. I like James's suggestion to allow us to store refs other than refs/heads/ in HEAD to denote this state, and keep commit and reset from updating such a ref through updating HEAD. We have code to prevent HEAD from pointing at anywhere outside refs/heads/ and that may even be an isolated single codepath we need to tweak. But I am reasonably sure that the layers above these core-level routines have their own checks to make sure HEAD is either detached or points at refs/heads/ somewhere; we would need to identify and change them as well. Also things like "git branch" need to be told that HEAD may point outside of refs/heads/ now to adjust their output style accordingly. They may probably strip refs/heads/ (or 11 bytes) assuming that attached HEAD will never point outside the local branch hierarchy. So I expect there will be tons of tiny fallouts from a change like that, but still it is conceptually simpler, and it would reduce the scope of detached HEAD to a temporary state that is not even worth being named with a branch name, which is exactly what it is. -- 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