{"thread":{"id":"23462","subject":"failed to lock","startedAt":"2010-04-14T20:49:09Z","lastAt":"2010-04-15T22:27:26Z","messageCount":6,"participants":["Jay Soffian","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139515","messageId":"j2o76718491004141349l53b53347v7f4c0edcab69e4c2@mail.gmail.com","threadId":"23462","inReplyTo":null,"subject":"failed to lock","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-04-14T20:49:09Z","receivedAt":"2010-04-14T20:49:09Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"With git-1.7, I regularly get this when pushing to a non-bare repo:\n\nremote: error: failed to lock refs/remotes/origin/master\n...\n ! [remote rejected] origin/master -> origin/master (failed to lock)\nerror: failed to push some refs to 'ssh://remote/repo'\n\nI see this pushing from a Mac, to either a Mac or to Cygwin. I have\nseen it on various versions of the 1.7 series and possibly before. In\nthe instance above:\n\nlocal git version 1.7.0.3.436.g2b878\nremote git version 1.7.0.3\n\nIn addition, the ref is (apparently) updated just fine. If I push a\nsecond time, no update occurs.\n\nThe problem is reproducible. Any idea where I should start debugging it?\n\nj.\n"},{"id":"139519","messageId":"t2i76718491004141402h33bb2044g155ef1715c63904e@mail.gmail.com","threadId":"23462","inReplyTo":"j2o76718491004141349l53b53347v7f4c0edcab69e4c2@mail.gmail.com","subject":"Re: failed to lock","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-04-14T21:02:52Z","receivedAt":"2010-04-14T21:02:52Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Wed, Apr 14, 2010 at 4:49 PM, Jay Soffian wrote:\n> The problem is reproducible. Any idea where I should start debugging it?\n\nAh, this is the problem:\n\n$ git push mirror\nTotal 0 (delta 0), reused 0 (delta 0)\nerror: Ref refs/remotes/origin/master is at\n81358fbe72926d74bdeda85669d655e144572c48 but expected\n3c0a87afc2e9248890dd6de40b5039bcb48c8516\nremote: error: failed to lock refs/remotes/origin/master\nTo ssh://mirror/repo\n 3c0a87a..81358fb origin/HEAD -> origin/HEAD\n ! [remote rejected] origin/master -> origin/master (failed to lock)\nerror: failed to push some refs to 'ssh://mirror/repo'\n\nThe origin/HEAD symref and --mirror do not get along together. Hmm.\n\nj.\n"},{"id":"139548","messageId":"k2x76718491004142100v6e1ece6djc62aa540e51eed5@mail.gmail.com","threadId":"23462","inReplyTo":"t2i76718491004141402h33bb2044g155ef1715c63904e@mail.gmail.com","subject":"Re: failed to lock","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-04-15T04:00:37Z","receivedAt":"2010-04-15T04:00:37Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Wed, Apr 14, 2010 at 5:02 PM, Jay Soffian wrote:\n> Ah, this is the problem:\n>\n> $ git push mirror\n> Total 0 (delta 0), reused 0 (delta 0)\n> error: Ref refs/remotes/origin/master is at\n> 81358fbe72926d74bdeda85669d655e144572c48 but expected\n> 3c0a87afc2e9248890dd6de40b5039bcb48c8516\n> remote: error: failed to lock refs/remotes/origin/master\n> To ssh://mirror/repo\n>   3c0a87a..81358fb  origin/HEAD -> origin/HEAD\n>  ! [remote rejected] origin/master -> origin/master (failed to lock)\n> error: failed to push some refs to 'ssh://mirror/repo'\n>\n> The origin/HEAD symref and --mirror do not get along together. Hmm.\n\nProposal: receive-pack should look through the list of heads it has\nreceived and check whether each is locally a symref. If so, and if the\ndestination of the symref is also among the list of heads, it should\nignore the symref update.\n\nIn the example above, receive-pack would determine that\nrefs/remotes/origin/HEAD locally is a symref to\nrefs/remotes/origin/master. Since refs/remotes/origin/master is in the\nlist of heads, it would ignore the update for\nrefs/remotes/origin/HEAD.\n\nIf that sounds reasonable, I can work on a patch.\n\nIn case you're wondering how I got into this situation:\n\nserver$ git clone --bare /shared/project.git ~/backup/project.git\nclient$ git clone server:/shared/project.git\nclient$ cd project\nclient$ git remote add --mirror backup server:~/backup/project.git\nclient$ work, commit, work, commit\nclient$ git push backup\n\nj.\n"},{"id":"139604","messageId":"7vd3y0k0c6.fsf@alter.siamese.dyndns.org","threadId":"23462","inReplyTo":"k2x76718491004142100v6e1ece6djc62aa540e51eed5@mail.gmail.com","subject":"Re: failed to lock","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-15T19:00:25Z","receivedAt":"2010-04-15T19:00:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n>> The origin/HEAD symref and --mirror do not get along together. Hmm.\n>\n> Proposal: receive-pack should look through the list of heads it has\n> received and check whether each is locally a symref.\n\nI would rather think that \"git push\" should notice that */HEAD is a symref\nand refrain from pushing it. Stated more precisely,\n\n - It is perfectly fine to do this:\n\n $ git push there HEAD:somebranch\n\n - But it does not make sense to push a symref via\n\n [remote \"there\"]\n \tpush = refs/*:refs/*\n\n to a bare repository that is used as a back-up mirror by including\n refs/HEAD:refs/HEAD in the result of wildcard expansion.\n"},{"id":"139613","messageId":"k2j76718491004151213xdb223ff8kd43f170eaf3a470a@mail.gmail.com","threadId":"23462","inReplyTo":"7vd3y0k0c6.fsf@alter.siamese.dyndns.org","subject":"Re: failed to lock","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-04-15T19:13:12Z","receivedAt":"2010-04-15T19:13:12Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Apr 15, 2010 at 3:00 PM, Junio C Hamano wrote:\n> I would rather think that \"git push\" should notice that */HEAD is a symref\n> and refrain from pushing it.  Stated more precisely,\n>\n>  - It is perfectly fine to do this:\n>\n>   $ git push there HEAD:somebranch\n>\n>  - But it does not make sense to push a symref via\n>\n>   [remote \"there\"]\n>        push = refs/*:refs/*\n>\n>   to a bare repository that is used as a back-up mirror by including\n>   refs/HEAD:refs/HEAD in the result of wildcard expansion.\n\nBut nothing prevents the destination repo from having arbitrary\nsymrefs. And there is no way for the source to know which destination\nrefs may be symrefs and which are not.\n\nSo it seems safer to me that the destination should ignore duplicates\nin the received list.\n\nNo?\n\nj.\n"},{"id":"139631","messageId":"7vbpdkic6p.fsf@alter.siamese.dyndns.org","threadId":"23462","inReplyTo":"k2j76718491004151213xdb223ff8kd43f170eaf3a470a@mail.gmail.com","subject":"Re: failed to lock","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-15T22:27:26Z","receivedAt":"2010-04-15T22:27:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> So it seems safer to me that the destination should ignore duplicates\n> in the received list.\n\nWe probably need it on both ends.\n\nOn the receiving end, it probably is a better idea to make verify_lock()\nsucceed if the ref has already been updated to the value we are going to\nupdate with, as I suspect that the issue is not limited to receive-pack.\nIt needs some restructuring of lock/verify/commit primitives, though.\n"}]}