From: Jeff King <peff@peff.net>
Date: Wed, 03 Jan 2007 10:46:20 GMT
Subject: Re: [PATCH] Detached HEAD (experimental)
Message-ID: <20070103104620.GA27015@coredump.intra.peff.net>
In-Reply-To: <7virfprquo.fsf@assigned-by-dhcp.cox.net>

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