Re: [1.8.0] Provide proper remote ref namespaces

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 14, 2011, 17:30 UTC
Message-ID: <7voc6ettgk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201102141059.12962.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 12 quoted lines

> On Mon, 14 Feb 2011, Johan Herland wrote:
>>>> Yes, replicating existing behavior w/explicit refspecs would look like: 
>>>>   [remote "origin"]
>>>>   
>>>>         url = git://git.example.com/repo.git
>>>>         fetch = +HEAD:refs/remotes/origin/HEAD
>
> Perhaps
>
>               setHead = master
>
> or something like that?

If I understand what Johan is saying correctly, I don't think that is solving any conceived problems. Currently origin/HEAD once initialized does not repoint and that behaviour more or less has been kept on purpose.

What it allows us by explicitly saying HEAD in the refspecs is to move away from the "origin/HEAD is under control of the local repository---it determines what you as the cloner consider the primary branch you are interested in in this particular remote" semantics and instead start saying "just like we copy the values of normal refs from the other side to keep track, we want origin/HEAD to _point at_ the branch they pointed at when we looked at them the last time". While I personally think that is also a valid thing to wish for, it probably is a bit too big a change in the semantics at this point.

If you mean by "setHead = master" to "set origin/HEAD symref to point at their master", that does not have to live in the config at all. Once you point the symref, nobody will repoint it to anywhere.

Show 8 quoted lines

>>> ... is meant to be used by the local
>>> repository to designate which of the remote branch is considered the
>>> primary branch from local repository owner's point of view, primarily so
>>> that you can say "origin" locally to mean "origin/next" by setting the
>>> symref origin/HEAD to point at it....
>
> Well, we have "git remote set-branch <remote> -a" to re-do this guessing
> or checking, and update 'remotes/origin/HEAD'...

That is exactly what I said, isn't it?

Show 6 quoted lines

>> Still (as I think was recently discussed in another thread), the existence 
>> of remotes/origin/HEAD _does_ cause problems if the origin remote also has a 
>> branch called "refs/heads/HEAD" (which would collide when fetched into the 
>> local repo).
>
> True, though... can't we consider having branch named 'HEAD' as insane?

There was a discussion to forbid ([ANYTHING_0-9A-Z]*_)?HEAD as a branch name to reduce confusion, and I think that is probably a sane thing to do without harming anybody in practice.