On Tue, Dec 11, 2012 at 11:46 AM, Junio C Hamano <gitster@xxxxxxxxx> 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? :-( -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html