Re: [PATCH] Detached HEAD (experimental)

From: Jeff King <peff@peff.net>
Date: Jan 3, 2007, 10:46 UTC
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