Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:33
Nicolas Pitre [off-list ref] 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.