Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Oct 13, 2009, 22:38 UTC
Message-ID: <20091013223821.GA15814@atjola.homenet>
In-Reply-To: <alpine.LNX.2.00.0910131654270.32515@iabervon.org>

On 2009.10.13 17:31:46 -0400, Daniel Barkalow wrote:

Show 11 quoted lines

> The other thing that I think would be nice is:
> 
> $ git checkout origin/next
> $ git fetch origin
> $ git checkout !! (probably not a good syntax)
> 
> That is, expand "!!" to the string used to detach HEAD, and expand it 
> again now. (Of course, something would have to be done if you did "git 
> checkout HEAD^1" before, or "git checkout !!^1".) This is related in that 
> I think the scary message should happen when "git commit" sees this stored 
> string and clears it.

That sounds somewhat like the "git up" hack I've shown here: http://article.gmane.org/gmane.comp.version-control.git/130050

In #git, Dscho even suggested that "git pull" could do that kind of DWIMmery while on a detached HEAD that waas reached by checking out a remote tracking branch. I'm undecided about that, because real merges/rebases could make it easier to lose work, as opposed to the "fast-forward only" behaviour I had in mind for that "git up" thing. Though of course, the "git pull" DWIMmery for a detached HEAD could simply refuse to do anything but a fast-forward.

Overall, I'm starting to think that improving the "work with a detached HEAD" area might be more worthwhile than adding DWIMmery that tries to completely avoid a detached HEAD.

This could include DWIMmery like the "git up"/"git pull" stuff, and improved security checks, like checking that leaving a detached HEAD doesn't "lose" any commits to the reflog. So checkout could do something like "git rev-list HEAD --not --all" (or does --all include HEAD?) and complain if there's something to be "lost".

Björn