# git remote set-head not working? 7 messages from 2009-12-18 to 2009-12-18. Participants: Eugene Sajine, Jeff King, Jay Soffian, Junio C Hamano. Thread: https://gitlist.dev/t/21983 ## Eugene Sajine, 2009-12-18 16:25 Subject: git remote set-head not working? Message-ID: <76c5b8580912180825t17bfc90eq20dfc05cafa8c02e@mail.gmail.com> URL: https://gitlist.dev/e/76c5b8580912180825t17bfc90eq20dfc05cafa8c02e%40mail.gmail.com ``` Hi, i have a repo cloned from the server with two branches master and qa. $git remote show origin tells me that the HEAD branch is master. When i try to execute $ git remote set-head origin qa It prints nothing and "git remote show origin" still prints that HEAD branch is master. Could you, please, advise if I am i missing something. I'm working on Linux with git-1.6.4.4 Thanks, Eugene ``` ## Jeff King, 2009-12-18 16:53 Subject: Re: git remote set-head not working? Message-ID: <20091218165302.GA1746@sigill.intra.peff.net> URL: https://gitlist.dev/e/20091218165302.GA1746%40sigill.intra.peff.net In-Reply-To: <76c5b8580912180825t17bfc90eq20dfc05cafa8c02e@mail.gmail.com> ``` On Fri, Dec 18, 2009 at 11:25:54AM -0500, Eugene Sajine wrote: > i have a repo cloned from the server with two branches master and qa. > > $git remote show origin > > tells me that the HEAD branch is master. > > When i try to execute > > $ git remote set-head origin qa > > It prints nothing and "git remote show origin" still prints that HEAD > branch is master. > > Could you, please, advise if I am i missing something. 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 ``` ## Eugene Sajine, 2009-12-18 17:38 Subject: Re: git remote set-head not working? Message-ID: <76c5b8580912180938s2b885efax33be860f963ba92f@mail.gmail.com> URL: https://gitlist.dev/e/76c5b8580912180938s2b885efax33be860f963ba92f%40mail.gmail.com In-Reply-To: <20091218165302.GA1746@sigill.intra.peff.net> ``` > 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 ``` ## Jay Soffian, 2009-12-18 21:28 Subject: Re: git remote set-head not working? Message-ID: <76718490912181328k5f87d82u499b7a1eba471126@mail.gmail.com> URL: https://gitlist.dev/e/76718490912181328k5f87d82u499b7a1eba471126%40mail.gmail.com In-Reply-To: <76c5b8580912180938s2b885efax33be860f963ba92f@mail.gmail.com> ``` On Fri, Dec 18, 2009 at 12:38 PM, Eugene Sajine wrote: > Yes. I was trying to change the HEAD on the bare remote (origin) repo > and the concept here is really confusing. The remote command is about updating things under .git/refs/remotes, not about updating a remote server. For updating a remote server, there is really only push. Clear as mud? > 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. It is expected that the person setting up the bare repo is the person who knows best which is the "default" branch. Which is why clone uses the remote HEAD as the default branch to checkout. But, if you don't like that, you can always use: % git clone -b master ... And you'll get master checked out instead of whatever the remote HEAD is. > 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? Hmm, the man page says: set-head Sets or deletes the default branch ($GIT_DIR/remotes//HEAD) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for origin is set to master, then origin may be specified wherever you would normally specify origin/master. This seems clear to me, but I guess if you expect that "git remote" updates the remote server I can see some confusion. Perhaps the DESCRIPTION for git remote should include something like: "This command updates the local repository only. For updating a remote repository, see git push." > 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. Understood. I'm not sure whether the send-pack/receive-pack protocol supports the notion of "I want to change what HEAD points to." j. ``` ## Junio C Hamano, 2009-12-18 21:42 Subject: Re: git remote set-head not working? Message-ID: <7veimst0w6.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7veimst0w6.fsf%40alter.siamese.dyndns.org In-Reply-To: <76718490912181328k5f87d82u499b7a1eba471126@mail.gmail.com> ``` Jay Soffian writes: > On Fri, Dec 18, 2009 at 12:38 PM, Eugene Sajine wrote: >> Yes. I was trying to change the HEAD on the bare remote (origin) repo >> and the concept here is really confusing. > > The remote command is about updating things under .git/refs/remotes, > not about updating a remote server. For updating a remote server, > there is really only push. Clear as mud? We still support (and unfortunately we would probably end up supporting for a long time) "remote update" so it is not strictly true, but that is the original motivation behind "git remote" subcommand. > Understood. I'm not sure whether the send-pack/receive-pack protocol > supports the notion of "I want to change what HEAD points to." It does not support it, but that is not because there is a strong reason it shouldn't. ``` ## Jay Soffian, 2009-12-18 22:24 Subject: Re: git remote set-head not working? Message-ID: <76718490912181424l3815ce95o6dcde77ea00cbd11@mail.gmail.com> URL: https://gitlist.dev/e/76718490912181424l3815ce95o6dcde77ea00cbd11%40mail.gmail.com In-Reply-To: <7veimst0w6.fsf@alter.siamese.dyndns.org> ``` On Fri, Dec 18, 2009 at 4:42 PM, Junio C Hamano wrote: > Jay Soffian writes: > >> The remote command is about updating things under .git/refs/remotes, >> not about updating a remote server. For updating a remote server, >> there is really only push. Clear as mud? > > We still support (and unfortunately we would probably end up supporting > for a long time) "remote update" so it is not strictly true, but that is > the original motivation behind "git remote" subcommand. But "remote update" updates the local repo from the remote, it doesn't do anything to the remote itself. That is the point I was trying to make clear -- "git remote" doesn't ever do anything to the remote repo, it only updates things on the local repo. >> Understood. I'm not sure whether the send-pack/receive-pack protocol >> supports the notion of "I want to change what HEAD points to." > > It does not support it, but that is not because there is a strong reason > it shouldn't. Okay. I'm sure deciding where to place the command "I want to update what HEAD on remote points to" would be a fun discussion. :-) j. ``` ## Eugene Sajine, 2009-12-18 23:55 Subject: Re: git remote set-head not working? Message-ID: <76c5b8580912181555i39484811t3aa641254c07dcce@mail.gmail.com> URL: https://gitlist.dev/e/76c5b8580912181555i39484811t3aa641254c07dcce%40mail.gmail.com In-Reply-To: <76718490912181328k5f87d82u499b7a1eba471126@mail.gmail.com> ``` > The remote command is about updating things under .git/refs/remotes, > not about updating a remote server. For updating a remote server, > there is really only push. Clear as mud? > > It is expected that the person setting up the bare repo is the person > who knows best which is the "default" branch. Which is why clone uses > the remote HEAD as the default branch to checkout. > > But, if you don't like that, you can always use: > > % git clone -b master ... didn't know that, thanks! >> 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? > > Hmm, the man page says: > >       set-head >           Sets or deletes the default branch ($GIT_DIR/remotes//HEAD) >           for the named remote. Having a default branch for a remote is not >           required, but allows the name of the remote to be specified in lieu >           of a specific branch. For example, if the default branch for origin >           is set to master, then origin may be specified wherever you would >           normally specify origin/master. > > This seems clear to me, but I guess if you expect that "git remote"... terms i'll use here: remote - instance created using git remote add or by cloning origin - actual remote repo I cloned from If it would be exactly as you said then it would probably not be so confusing. The problem here is that if set-head is only about the remote, then why after i change it from master to qa and "git show remote origin" doesn't show this change? Bug? Probably, because "git show remote origin" actually queries origin for this info and always shows origin HEAD branch, as Jeff pointed out. If this is the case then there is an inconsistency between those two commands which caused this confusion. Please, correct me If i'm wrong but i really think that there should be a way to not only set it up for remote but also for origin , where the remote points to if you have push rights of course. Of course all of this could be avoided if I knew that i have to be explicit during cloning from my colleagues, because their HEAD may be pointing to some BUTT, which I don't even want to know about;) Thanks, Eugene ```