On Thu, Oct 15, 2009 at 02:54:18PM -0700, Junio C Hamano wrote: > Maybe we are reading different messages in the same message. > > My understanding of James's suggestion is: > > (1) "git checkout $token" makes HEAD point at the refname dwim_ref() > expands $token to, iff dwim_ref() is happy, and otherwise detaches > HEAD; > > (2) "git commit" (and other things like "git reset HEAD^" that updates > underlying ref thru updates to HEAD when HEAD is a symref) rejects > when HEAD points at a ref outside refs/heads/, but works when HEAD > points at a local branch, or when HEAD is detached. Right. I thought the idea of "don't complain at checkout time, but complain at commit" had been considered and rejected. But I guess you could argue that the difference between this and the original discussion is that we are going to have _both_ the detached HEAD state and the "refs/tags/* in HEAD" state, and treat them differently. I feel like the latter idea was discussed in more detail (I made reference to it in the latter email I linked to, but I don't think that was the origin of it), but I can't seem to find any discussion. So I will buy that this is somewhat of a new idea. I am still confused about what happens with this, though: $ git checkout origin/next $ git fetch ;# updates origin/next Do we refuse the fetch? Does the user now have a working tree and index that doesn't match their HEAD? > This is backward incompatible, and makes what experts are used to do > slightly cumbersome to spell, i.e. > > $ git checkout v1.6.5^0 ;# detaches and can commit > $ git checkout origin/next^0 ;# ditto > $ git checkout $(git merge-base master sp/smart-http) ;# ditto I think it is less cumbersome if we add "git checkout -d v1.6.5" (well, same number of characters, but a lot less ugly). Assuming that the rest of it is a good idea. -Peff -- 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