> Hmm. It probably worked, but what you are being shown is a bit > confusing. > > "git remote show" will actually query the remote server to find where > its HEAD is pointing. But "git remote set-head" is about changing your > _local_ idea of where the remote head is pointing (in general, "git > remote" does not change anything on the remote side. It is about > managing the local configuration of your remotes). > > AFAICT, there is no way to use "git remote" to query the result of your > set-head. And the "show" output makes no distinction between the two. > > Perhaps we should print both in "git remote show" if they differ. > Something like: > > HEAD branch: qa (remote points to "master") > > or > > HEAD branch (local): qa > HEAD branch (remote): master > > That would clear up the confusion of what is happening. Whether that is > what you actually wanted, I don't know. If you want to be able to refer > to "origin/qa" as "origin", then you're fine. But if you wanted to > actually change the remote repository's idea of HEAD so that further > clones will clone "qa" by default, then you can't do that with "git > remote". You would have to go to the remote repository and run "git > symbolic-ref", I think. > > -Peff > Yes. I was trying to change the HEAD on the bare remote (origin) repo and the concept here is really confusing. Firstly, when i cloned from some repo "clone" comand is setting HEAD branch for remote in accordance to where the HEAD is pointing on origin side. I just recently realized that and i'm not sure it is best thing to do - i think it should default to origin/master first, if it doesn't exist then to where the HEAD is pointing. Secondly, I don't really understand what is the purpose of "git remote set-head" if the change cannot be transferred to the actual origin repo, so it will start serving another branch as default? I might not have access to the server to perform git symbolic-ref on my bare repo (imagine the repo on github), so it might be not an option. The problem with this is that it can be screwed up easily (i did it;)), but the fix is not trivial. Scenario i hit was: My colleague created bare repo on the server and performed some commits and pushed. We've got 3 branches on the server: master, qa and featureX The repo got screwed up - i was unable to clone because of repository corruption (another story probably for Shawn as there was Egit involved;) ) So i tried to recover I cloned from my colleague, but his head was pointing to featureX so I've got this featureX, when i was expecting to see master. I realized that i have to add master and qa as tracking branches for origin/master and origin/qa. Then i deleted corrupted server repo, created bare repo using "clone --bare" and put it on the server. But i didn't know that i have to checkout to master branch in order for it to be default branch served from the server before cloning. So i ended up with the featureX being default HEAD on the server. That was not user friendly stuff... And here i am trying to change this setting on the server... Thanks, Eugene -- 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