Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help