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

[Nicolas Pitre <nico@fluxnic.net>]

On Thu, 15 Oct 2009, Jakub Narebski wrote:

> James Pickens <jepicken@gmail.com> writes:
> 
> > 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.)

I don't think detached head is scary at all (unless viewed in another 
context other than git) but if that encounter can be kept away from most 
users without denying its use then all for the better.

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

I do like and actively use manual committing on a detached HEAD as well, 
so please let's not forget about that use case.

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

Sure.

>   $ 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]":

... or the current "this is not a local branch -- use checkout -b to 
create one" warning, just like what we have today when checking out a 
tag or remote branch, except that the warning is deferred to the commit 
operation which in fact might even not take place.

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

I wouldn't go too far in that direction though.  Too many suggestions 
would simply bring back confusion to the new user who at that point 
might not even understand yet what all the different concepts are.


Nicolas