git remote set-head not working?

git remote set-head not working?

[Eugene Sajine]

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

Re: git remote set-head not working?

[Jeff King]

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

Re: git remote set-head not working?

[Eugene Sajine]

> 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

Re: git remote set-head not working?

[Jay Soffian]

On Fri, Dec 18, 2009 at 12:38 PM, Eugene Sajine <euguess@gmail.com> 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/<name>/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.

Re: git remote set-head not working?

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> On Fri, Dec 18, 2009 at 12:38 PM, Eugene Sajine <euguess@gmail.com> 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.

Re: git remote set-head not working?

[Jay Soffian]

On Fri, Dec 18, 2009 at 4:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> 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.

Re: git remote set-head not working?

[Eugene Sajine]

> 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/<name>/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