On Tue, Jan 02, 2007 at 02:44:31PM -0800, Junio C Hamano wrote: > necessarily a better option of the two. We could allow commits > and prevent the user from switching out of the detached HEAD > state without an explicit action instead. If we go the first I think you should only enact this safety valve if there have actually been commits. Otherwise, people who are just tracking and do a "git-checkout v1.4.0; look look look; git-checkout v1.5.0" will get a confusing message. Personally, I like the "don't allow commit without a branch" approach, but only if you can "git-commit -b newbranch" and "git-merge -b newbranch" to make it convenient to create a branch. Making commits that aren't on any branch seems like a broken state (and indeed, you have to use special options to get out of the state); it makes more sense to me to never enter the state in the first place. Also, the implementation should be conceptually simple. Put refs/tags/v1.4.0 into HEAD on checkout. Disallow commit/merge unless HEAD points to refs/heads/*. Just my 2 cents... -Peff - 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