Hi, Dun Peal wrote: > The problem is that since there's no head pointing to each release, if > our users just: > > $ git checkout release-1 > > When they want to build that release, they get into a detached HEAD > state. I've always construed detached HEAD as a non-standard state, > and it doesn't seem proper to reach it regularly in the course of a > standard operation like checking out past releases. > > It's particularly confusing for our users who are new to Git. Any ideas for making the detached state more friendly? The idea is this: when you check out a tag or a remote-tracking branch, it is not to make changes to it. Tags are unchanging, remote-tracking branches track remote state that the user does not directly control. So what does it mean to check out such a thing? There are two possibilities: If you are checking out that commit to examine it, test it, maybe write a few one-off patches, then any work built from there does not need to be remembered (except in the HEAD reflog, to avoid expensive accidents). You can make an experiment permanent with git checkout -b newbranch If you are starting a new line of development, it needs to get a name. Long ago this was the only use case supported. Even today it is often a good way to go: git checkout -b newbranch release-1 Hope that helps. Jonathan -- 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