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

> On Thu, 15 Oct 2009, James Pickens wrote:
> 
>> On Wed, Oct 14, 2009 at 4:09 PM, Jeff King <peff@peff.net> wrote:
>>> That makes the most sense to me. If "git checkout" could write metadata
>>> into HEAD (or into DETACH_HEAD, as in Daniel's patch), then checkout
>>> could record an "ok to commit" bit. And could also be used to change it
>>> after the fact. E.g.:
>>>
>>>  $ git checkout --detach=commit origin/master
>>>  $ git commit ;# should be ok
>>>
>>>  $ git checkout --detach=examine origin/master
>>>  $ git commit ;# complain
>>>  $ git checkout --detach=commit HEAD
>>>  $ git commit ;# ok
>>>
>>> I guess something like "rebase" should detach with "ok to commit", since
>>> it is planning on attaching the commits later. I'm not sure about "git
>>> bisect". I guess probably it should be "not ok to commit" to be on the
>>> safe side, and then somebody can "git checkout --detach=commit" if they
>>> want to.
>>
>> How about not detaching the head at all if the user checks out any ref, and
>> reject commits if he checked out a tag or remote branch.  For example:
>>
>> $ git checkout origin/master
>> $ git status
>> # On branch origin/master
>> $ git commit ;# complain
>>
>> $ git checkout v1.0.1
>> $ git status
>> # On tag v1.0.1
>> $ git commit ;# complain
>>
>> $ git checkout v1.0.1^0 ;# detach
>> $ git commit ;# ok
>>
>> I think this would help the newbies and wouldn't cost the experts too much.
>> Checking out anything other than a plain ref would still detach the head, and
>> commits on a detached head would still be allowed.
> 
> I think reducing users' exposure to the "detached HEAD" state would just 
> make it take longer for them to find that state familiar.

> It's not like the concept is actually very difficult or unusual. CVS has 
> it as "cvs checkout -r <something>" or "cvs checkout -D <something>"; SVN 
> has it as "svn checkout -r <something>". It was weird and scary in CVS if 
> you did it (it was "sticky tags", and you had to find a different option 
> to get back to normal), but SVN is easier ("svn checkout -r HEAD").

> I think the description used in CVS and SVN (and, I think, others) is that 
> you're not at the HEAD revision. I think they both account for the state 
> where you've checked out the revision by number that's the latest 
> revision, but you still can't grow the branch because you can't 
> simultaneously stay on r1000 (as requested explicitly) and add a new 
> commit.

> So maybe the right explanation is:
> 
> $ git checkout master; git branch
> * master
> $ git checkout origin/master; git branch
> * origin/master (not at head)

> $ git checkout 123cafe^5; git branch
> * 123cafe^5 (not at head)
> $ git checkout HEAD^2; git branch
> * 123cafe^5^2
> $ git commit; git branch
> * (temporary branch)
> 
> Then we can say that one way that git is different from SVN is that all 
> branches of other repositories are read-only, and you can't be at the 
> head when you're on them (because the head of those branches are in 
> different repositories); instead you grow the history locally, and you 
> tell the remote branch to adopt your history.

>> Perhaps as an additional safety feature, Git could refuse to switch away 
>> from a detached head if the head isn't reachable from any ref
> 
> As far as I know, people don't actually seem to lose stuff this way. In 
> part, that's because they get scared before they get there; in part, 
> that's because they just don't think to go there; and in part, we tell 
> them how to recover stuff at that point (using the ref log or the sha1).