Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 15, 2009, 19:52 UTC
Message-ID: <7v1vl45t9k.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.0910151436180.20122@xanadu.home>

Nicolas Pitre <nico@fluxnic.net> 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.