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

[Michael J Gruber <git@drmicha.warpmail.net>]

Daniel Barkalow venit, vidit, dixit 15.10.2009 17:36:
> 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.

Yep. Which is why I keep suggesting that git clone does not create any
local branches at all ;)

> 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").

svn up -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.

I'd say the fundamental difference is that in CVS and SVN, there is
always only one "tip", which they call HEAD. This is also why revision
numbers make sense.

In git and hg there can be many tips (branch heads) from which to grow
the DAG. Heck, you can grow a new one from any commit ;)

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

Ouch, please don't. HEAD has a completely different meaning in git. I
know you know, of course.

> $ 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.

You can change your refs/remotes/origin/master, of course, it's just by
convention (for a good reason) that git treats them as read-only, and
porc. respects that.

git's branches are simply completely different, they're movable tags,
and I think that's one point new users *have* to grok. Once they're over
this then even detached heads are a natural thing.

>> 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).

Maybe we just don't scare them enough yet :)

Michael