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

From: Jakub Narebski <jnareb@gmail.com>
Date: Oct 15, 2009, 12:54 UTC
Message-ID: <m3bpk8g6nj.fsf@localhost.localdomain>
In-Reply-To: <885649360910150036o72c3bd97ofad85d5316dc5b35@mail.gmail.com>

James Pickens <jepicken@gmail.com> writes:

Show 19 quoted lines

> 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 it is a very good idea.

This makes it easy to checkout remote-tracking branch or a tag for viewing, something that was (I think) one of problems (use cases) that lead to invention of detached HEAD... and then it turned out that detached HEAD (unnamed branch) is scary for newbie git users. (So the difficulty of having to create new branch or rewind some branch to view non-committable ref was replaced by scary detached HEAD concept.)

With this idea there are no problems with git commands that use detached HEAD such as git-bisect (which uses it in viewing mode, but then skips through history, so detached HEAD is a good solution here) or git-rebase (which does committing on detached HEAD for easier aborting and cleanup).

Let me propose additional feature: "smart" (context sensitive) warnings, namely that in the following sequence

  $ git checkout origin/master
  $ git status
  # On remote-tracking branch origin/master of remote origin
  # ...

  $ git commit

'git commit' would refuse committing on non-heads ref, and propose, beside _always_ proposing detaching HEAD and committing on such detached HEAD (unnamed branch) via "git checkout HEAD^0", or "git checkout --detach [HEAD]":

1. If there is no local branch which follows 'origin/master'
   (which has 'origin/master' as upstream, which tracks 'origin/master')
   propose creating it before comitting:

    $ git checkout -t origin/master

2. If there is single local branch that follows 'origin/master',
   and it fast-forwards to 'origin/master' propose... 
   errr, something that would mean fast-forwarding this branch
   and making a commit on local branch that has 'origin/master'
   as upstream.
   
3. If there is single local branch that follows 'origin/master', but
   it has changes / diverges from 'origin/master' we are viewing,
   propose... hmmm, what then?

4. If there are more than one local branch that has 'origin/master'
   as upstream, list all those branches in message.

Show 11 quoted lines

> 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,
> and require -f to override:
> 
> $ git checkout $sha1
> $ git commit
> $ git checkout master ;# complain
> $ git checkout -f master ;# ok
> 
> Maybe I'm missing something and this all can't be done, but it seems simpler
> than the other options I've seen in this thread.

I'm not sure about overloading '-f' option, unless we would require doubled '-f' for overriding both safety checks: checkout from detached HEAD, and current meaning of forcing a switch even if index or the working are differs from HEAD. So you would need

  $ git checkout -f -f master

if you are on detached HEAD and have uncommitted changes (dirty tree or dirty index).

-- 
Jakub Narebski
Poland
ShadeHawk on #git