Re: [RFC/PATCH] ignoring a fetch that overwrites local symref

[Shawn Pearce <spearce@spearce.org>]

On Tue, Dec 11, 2012 at 11:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> This is a companion to an ancient thread
>
>     http://thread.gmane.org/gmane.comp.version-control.git/145311/focus=145337
>
> in which an error was dealt with while pushing into a "mirror"
> repository that has a symbolic reference refs/remotes/origin/HEAD
> pointing at refs/remotes/origin/master with "git push --mirror".
> The issue was that the receiving end was told to update origin/HEAD
> and origin/master separately; if origin/HEAD is updated, that would
> update origin/master at the same time, and then when attempting to
> update origin/master, it would notice that it no longer has the
> expected old value and barf.  After the series, we started ignoring
> such pushes to HEAD on the receiving end.
>
> But you can suffer from a similar issue transferring objects in the
> opposite direction.  If you run "fetch --mirror" in to such a
> "mirror" repository, the other side would advertise both 'master'
> and 'HEAD' under refs/remotes/origin/ hierarchy, and refs/*:refs/*
> wildcard would try to grab both of them.
>
> Work it around by noticing a wildcard match that attempts to update
> a local symbolic ref and ignoring it.

At what point should we just support symrefs on the protocol? :-(