Re: Creating remote branch called HEAD corrupts remote clones

[Jeff King <peff@peff.net>]

On Thu, Jan 20, 2011 at 11:53:16AM -0800, Junio C Hamano wrote:

> The refs/remotes/origin/HEAD in Bob's repository is supposed to be a
> symbolic ref that points at the primary branch of the 'origin' remote
> (typically its master), e.g. "ref: refs/remotes/origin/master".  But in
> general, local 'refs/remotes/origin/X' for any value of X is to copy
> 'refs/heads/X' from the 'origin'.
> 
> Oops.  If the origin repository has 'refs/heads/HEAD', these rules
> obviously conflict with each other.
>
> [...]
>
> I personally think it is reasonable to forbid HEAD or anything all caps
> that ends with "_HEAD" as branch names.  Opinions?

Hmm. It seems like the symbolic ref is the culprit, not just HEAD. The
HEAD thing is the most likely, of course, but I could do something like:

  git symbolic-ref refs/remotes/origin/convenient-alias \
                   refs/remotes/origin/some-name-you-dont-like

which is basically the same as the HEAD case (except that the
"convenient alias" for HEAD is "origin" and not
"origin/convenient-alias" due to the lookup table in dwim_ref).

Now imagine the remote creates a branch called convenient-alias. When I
fetch, am I corrupting my local tracking branches by falsely equating
the two? And/or when I push, am I then corrupting the remote?

So I wonder if the safety valve here should be about symbolic refs, and
not about the special name HEAD. Maybe we should not follow symbolic
refs during fetch. So if we are fetching the refspec "foo:bar", and the
RHS "bar" is a symref, we should _not_ follow it, but instead just
overwrite the symref with a regular ref.

For pushing, one rule could be to allow pushing from a named symref, but
not allow the matching rules to use a symref as a source. So I could do:

  git push origin convenient-alias:new-name

but

  git push origin

would never overwrite upstream's convenient-alias.

I dunno. That's just off the top of my head, so maybe I'm missing some
corner cases. I would be tempted to put the push rule into receive-pack,
so it could look at the local refs, but I don't think receive-pack has
any way of knowing what is a symref and what is not on the pushing end.

-Peff