On 2009.10.13 17:31:46 -0400, Daniel Barkalow wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html