{"thread":{"id":"38942","subject":"rename a remote does not update pushdefault (v1.9.5)","startedAt":"2015-03-30T09:28:30Z","lastAt":"2015-03-31T03:52:56Z","messageCount":3,"participants":["Alexander Duytschaever","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"258667","messageId":"B2C5B27F9C4A45469123297E3F6BCF0C55DA0AEA07@XMAIL08.UGent.be","threadId":"38942","inReplyTo":null,"subject":"rename a remote does not update pushdefault (v1.9.5)","fromName":"Alexander Duytschaever","fromEmail":"alexander.duytschaever@ugent.be","sentAt":"2015-03-30T09:28:30Z","receivedAt":"2015-03-30T09:28:30Z","isPatch":false,"sender":{"key":"alexander.duytschaever@ugent.be","avatar":null},"body":"When defining pushdefault and renaming the associated remote, the pushdefault setting becomes invalid. Instead, it should follow the renamed remote if that was designated as pushdefault.\n\nTest procedure:\n\n1. Create/cd empty directory\n2. `git init .`\n3. `git remote add abc def`\n4. Observe that `git remote` now shows 'abc'\n5. `git config default.pushdefault abc`\n6. Observe that `git config --list` shows default.pushdefault=abc\n7. `git remote rename abc xyz`\n\nBUG: observe that pushdefault still refers to 'abc', while it should now refer to 'xyz'.\n\nRgds\n\n(Initially (wrongly) filed as TGit bug: https://code.google.com/p/tortoisegit/issues/detail?id=2438)\n"},{"id":"258686","messageId":"xmqq384mxoka.fsf@gitster.dls.corp.google.com","threadId":"38942","inReplyTo":"B2C5B27F9C4A45469123297E3F6BCF0C55DA0AEA07@XMAIL08.UGent.be","subject":"Re: rename a remote does not update pushdefault (v1.9.5)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-30T19:39:17Z","receivedAt":"2015-03-30T19:39:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexander Duytschaever <Alexander.Duytschaever@UGent.be> writes:\n\n> When defining pushdefault and renaming the associated remote, the\n> pushdefault setting becomes invalid. Instead, it should follow the\n> renamed remote if that was designated as pushdefault.\n>\n> Test procedure:\n>\n> 1. Create/cd empty directory\n> 2. `git init .`\n> 3. `git remote add abc def`\n> 4. Observe that `git remote` now shows 'abc'\n> 5. `git config default.pushdefault abc`\n> 6. Observe that `git config --list` shows default.pushdefault=abc\n\nI do not think we have default.pushdefault.  Perhaps you meant\nremote.pushdefault, but even then, I do not think we usually set\nthat up by default.\n\n> 7. `git remote rename abc xyz`\n>\n> BUG: observe that pushdefault still refers to 'abc', while it should now refer to 'xyz'.\n\nAgain,  by default remote.pushDefault is not set up by us, so there\nis nothing to comment here.\n\n> (Initially (wrongly) filed as TGit bug:\n\nPerhaps TGit is setting remote.pushDefault?  If so, I would say a\nbug (if there is a bug, which I highly doubt; see below) belongs\nthere.\n\nHaving said all that, if you did this instead, you will see that\nremote.pushdefault will not change:\n\n    $ git init\n    $ git remote add abc def\n    $ git config remote.pushdefault abc\n    $ git config remote.pushdefault\n    abc\n    $ git remote rename abc xyz\n    $ git config remote.pushdefault\n    abc\n\nand I can see this argued both ways.\n\n1. Imagine you so far had three remotes A, B and DEFAULT defined,\n   among which the last one was the default push destination, like\n   this:\n\n       [remote]\n           pushDefault = DEFAULT\n       [remote \"A\"]\n           url = http://a.xz/project\n       [remote \"B\"]\n           url = http://b.xz/project\n       [remote \"DEFAULT\"]\n           url = http://c.xz/project\n\n   and for whatever reason, you decided c.xz should not be the default\n   place for you to push to, but instead you want to make b.xz the\n   default.  It is conceivable that you would expect this to work:\n\n       $ git remote rename DEFAULT C\n       $ git remote rename B DEFAULT\n    \n   to give you this:\n\n       [remote]\n           pushDefault = DEFAULT\n       [remote \"A\"]\n           url = http://a.xz/project\n       [remote \"DEFAULT\"]\n           url = http://b.xz/project\n       [remote \"C\"]\n           url = http://c.xz/project\n\n   And for that use case, remaing remote.pushDefault is absolutely the\n   wrong thing to do.  After the \"rename DEFAULT C\", remote.pushDefault\n   must not be moved to C, because the next \"rename B DEFAULT\" will not\n   be able to guess that remote.pushDefault wants to become DEFAULT.\n\n2. On the other hand, starting from the same \"A, B and DEFAULT\"\n   state, you may be trying to rename DEFAULT everywhere to C to\n   come to this instead:\n\n       [remote]\n           pushDefault = C\n       [remote \"A\"]\n           url = http://a.xz/project\n       [remote \"B\"]\n           url = http://b.xz/project\n       [remote \"C\"]\n           url = http://c.xz/project\n\n   And for that use case, not remaing remote.pushDefault will appear to\n   be a bug, as remote.pushDefault will be left as DEFAULT.\n\nWhichever way you implement \"remote rename\", you will make half of\nthe users happy while making other half unhappy.  One use case will\nbe happier if remote.pushdefault is left intact; the other use case\nwill be happier if remote.pushdefault is updated.  There are two\nsides to this coin.\n\nI think the implementation took the most straight-forward path to\nsay \"we rename everything inside remote.C.* section and adjust the\nrefspecs for remote-tracking branches because that is what appear in\nthat section\"; which allows the first use case and the second use\ncase would be just a single \"git config remote.pushDefault C\" away.\n\nIf you change what the command does this late in the game, then not\nonly you will upset people who have been happy with the current\nbehaviour (mostly those who used the first scenario), but you will\nnot really help people who may have wished that remote.pushDefault\nto be adjusted either, because they are already used to do the final\n\"git config remote.pushDefault C\" anyway.\n\nSo...\n"},{"id":"258728","messageId":"20150331035256.GA1408@peff.net","threadId":"38942","inReplyTo":"xmqq384mxoka.fsf@gitster.dls.corp.google.com","subject":"Re: rename a remote does not update pushdefault (v1.9.5)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-31T03:52:56Z","receivedAt":"2015-03-31T03:52:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 30, 2015 at 12:39:17PM -0700, Junio C Hamano wrote:\n\n> Whichever way you implement \"remote rename\", you will make half of\n> the users happy while making other half unhappy.  One use case will\n> be happier if remote.pushdefault is left intact; the other use case\n> will be happier if remote.pushdefault is updated.  There are two\n> sides to this coin.\n> \n> I think the implementation took the most straight-forward path to\n> say \"we rename everything inside remote.C.* section and adjust the\n> refspecs for remote-tracking branches because that is what appear in\n> that section\"; which allows the first use case and the second use\n> case would be just a single \"git config remote.pushDefault C\" away.\n\nI had a similar thought. But note that we do update \"branch.*.remote\"\nthat points to the renamed remote. So it seems inconsistent that we do\nnot similarly update \"branch.*.pushremote\". And if we update that, it\nseems inconsistent that we do not update \"remote.pushdefault\".\n\nIn other words, we should probably choose to update all references or\nnone, but we are currently somewhere in between. Of course, the fact\nthat the code has been in this limbo for so long makes it doubly\nawkward, as we do not know what people expect (and what they simply\nconsider a bug).\n\nSo I don't know what the right answer is.\n\nI did take a peek at the code. I don't think updating these variables\nwould be too hard, but there needs to be some refactoring around\nremote.c's pushremote_name.  After calling read_config(), we do not have\na value that exactly corresponds to remote.pushdefault; we overwrite it\nwith the branch-specific pushremote if there is one.\n\n-Peff\n"}]}