Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano <gitster@pobox.com>]

Jakub Narebski <jnareb@gmail.com> writes:

> 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.

>>> ... 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?

>> 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.