On Thu, Jun 02, 2011 at 10:02:31PM +0200, Jakub Narebski wrote: > > No, that is always supposed to be a symbolic ref. Making it a real ref > > would be confusing. I don't think fetch should look at HEAD at all; it's > > outside its refspec. However, clone does treat HEAD specially, and > > should probably convert the remote's detached HEAD into a local detached > > HEAD (we already do if it's part of referenced history). > > Hmmm... in ordinary case (not on detached HEAD) "git fetch" would never > modify my local branches nor my local HEAD. Right. Fetch should never touch those things. Nor should it ever touch refs/remotes/$remote/HEAD, as that is not really "where is the remote HEAD pointing" but rather "what would I like the alias $remote to point to"? Clone sets it to the remote HEAD, as that is the most obvious choice; but if the user changes it, we should leave their choice in place. > On the other hand IIRC origin/HEAD do not follow switching branches at > origin, and is staying at the value at clone (or "git remote > set-head"), isn't it? Right. > So what to do when HEAD on origin is detached? Modify .git/HEAD, or > maybe .git/refs/remotes/origin/HEAD? I don't think fetch should do _anything_ with the remote HEAD. It's outside of its refspec scope. This is purely about what clone should do, and that's an easier problem, because it's not "modify" but rather "create". -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