{"thread":{"id":"45127","subject":"git remote rename problem with trailing \\\\ for remote.url config entries (on Windows)","startedAt":"2017-02-13T16:49:25Z","lastAt":"2018-04-10T23:31:24Z","messageCount":4,"participants":["Marc Strapetz","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"311410","messageId":"da730b21-58ae-bfa8-705f-7669c0f56764@syntevo.com","threadId":"45127","inReplyTo":null,"subject":"git remote rename problem with trailing \\\\ for remote.url config entries (on Windows)","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2017-02-13T16:49:44Z","receivedAt":"2017-02-13T16:49:25Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"One of our users has just reported that:\n\n$ git remote rename origin origin2\n\nwill turn following remote entry:\n\n[remote \"origin\"]\n\turl = c:\\\\repo\\\\\n\tfetch = +refs/heads/*:refs/remotes/origin/*\n\ninto following entry for which the url is skipped:\n\n[remote \"origin2\"]\n[remote \"origin2\"]\n\tfetch = +refs/heads/*:refs/remotes/origin2/*\n\nI understand that this is caused by the trailing \\\\ and it's easy to \nfix, but 'git push' and 'git pull' work properly with such URLs and a\n\n$ git clone c:\\repo\\\n\nwill even result in the problematic remote-entry. So I guess some kind \nof validation could be helpful.\n\nTested with git version 2.11.0.windows.1\n\n-Marc\n\n\n\n\n"},{"id":"311416","messageId":"xmqqo9y6dj1s.fsf@gitster.mtv.corp.google.com","threadId":"45127","inReplyTo":"da730b21-58ae-bfa8-705f-7669c0f56764@syntevo.com","subject":"Re: git remote rename problem with trailing \\\\ for remote.url config entries (on Windows)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-13T18:47:43Z","receivedAt":"2017-02-13T18:47:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Strapetz writes:\n\n> One of our users has just reported that:\n>\n> $ git remote rename origin origin2\n>\n> will turn following remote entry:\n>\n> [remote \"origin\"]\n> \turl = c:\\\\repo\\\\\n> \tfetch = +refs/heads/*:refs/remotes/origin/*\n>\n> into following entry for which the url is skipped:\n>\n> [remote \"origin2\"]\n> [remote \"origin2\"]\n> \tfetch = +refs/heads/*:refs/remotes/origin2/*\n>\n> I understand that this is caused by the trailing \\\\ and it's easy to\n> fix, but 'git push' and 'git pull' work properly with such URLs and a\n>\n> $ git clone c:\\repo\\\n>\n> will even result in the problematic remote-entry. So I guess some kind\n> of validation could be helpful.\n\nIf you change the original definition of the \"origin\" to\n\n [remote \"origin\"]\n url = \"c:\\\\repo\\\\\"\n fetch = +refs/heads/*:refs/remotes/origin/*\n\nor\n\n [remote \"origin\"]\n url = c:\\\\repo\\\\ # ends with bs\n fetch = +refs/heads/*:refs/remotes/origin/*\n\nit seems to give me a better result. I didn't dig to determine\nwhere things go wrong in \"remote rename\", and it is possible that\nthe problem is isolated to that command, or the same problem exists\nwith any value that ends with a backslash. If the latter, \"git clone\"\nand anything that writes to configuration such a value needs to be\ntaught about this glitch and learn a workaround, I would think.\n\nDscho Cc'ed, not for Windows expertise, but as somebody who has done\na lot in .\n\n\n\n"},{"id":"344421","messageId":"nycvar.QRO.7.76.6.1804110020380.56@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"45127","inReplyTo":"xmqqo9y6dj1s.fsf@gitster.mtv.corp.google.com","subject":"Re: git remote rename problem with trailing \\\\ for remote.url config entries (on Windows)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-04-10T22:35:08Z","receivedAt":"2018-04-10T23:01:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[I know, blast from the past...]\n\nOn Mon, 13 Feb 2017, Junio C Hamano wrote:\n\n> Marc Strapetz writes:\n> \n> > One of our users has just reported that:\n> >\n> > $ git remote rename origin origin2\n> >\n> > will turn following remote entry:\n> >\n> > [remote \"origin\"]\n> > \turl = c:\\\\repo\\\\\n> > \tfetch = +refs/heads/*:refs/remotes/origin/*\n> >\n> > into following entry for which the url is skipped:\n> >\n> > [remote \"origin2\"]\n> > [remote \"origin2\"]\n> > \tfetch = +refs/heads/*:refs/remotes/origin2/*\n> >\n> > I understand that this is caused by the trailing \\\\ and it's easy to\n> > fix, but 'git push' and 'git pull' work properly with such URLs and a\n> >\n> > $ git clone c:\\repo\\\n> >\n> > will even result in the problematic remote-entry. So I guess some kind\n> > of validation could be helpful.\n> \n> If you change the original definition of the \"origin\" to\n> \n> [remote \"origin\"]\n> url = \"c:\\\\repo\\\\\"\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> \n> or\n> \n> [remote \"origin\"]\n> url = c:\\\\repo\\\\ # ends with bs\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> \n> it seems to give me a better result. I didn't dig to determine\n> where things go wrong in \"remote rename\", and it is possible that\n> the problem is isolated to that command, or the same problem exists\n> with any value that ends with a backslash. If the latter, \"git clone\"\n> and anything that writes to configuration such a value needs to be\n> taught about this glitch and learn a workaround, I would think.\n> \n> Dscho Cc'ed, not for Windows expertise, but as somebody who has done\n> a lot in .\n\nSo... I finally had a look at this, and while I agree that the quoted\nversion is better, I also agree that the backslash is mistaken for a\ncontinuation character (which is not even allowed in section headers).\n\nA quick test with my `empty-config-section` patch series shows that it\naddresses this issue. A quick bisec confirms that the patch with the\nonline \"git_config_set: make use of the config parser's event stream\" is\nresponsible for this fix.\n\nAt first, I was puzzled by this, because I expected `git remote rename` to\nbe backed by the `git_config_copy_or_rename_section_in_file()` function\n(which my patch series does not touch).\n\nBut then I looked at the code of the `mv()` function in builtin/remote.c\nand it uses `git_config_set_multivar()` and `git_config_set()`. And those\nfunctions were indeed touched (and fixed) by above-mentioned commit.\n\nCiao,\nJohannes\n"},{"id":"344422","messageId":"xmqq8t9u1vwd.fsf@gitster-ct.c.googlers.com","threadId":"45127","inReplyTo":"nycvar.QRO.7.76.6.1804110020380.56@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: git remote rename problem with trailing \\\\ for remote.url config entries (on Windows)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-04-10T23:31:14Z","receivedAt":"2018-04-10T23:31:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> A quick test with my `empty-config-section` patch series shows that it\n> addresses this issue. A quick bisec confirms that the patch with the\n> online \"git_config_set: make use of the config parser's event stream\" is\n> responsible for this fix.\n>\n> At first, I was puzzled by this, because I expected `git remote rename` to\n> be backed by the `git_config_copy_or_rename_section_in_file()` function\n> (which my patch series does not touch).\n\nI played around with this test data:\n\n [sec \"tio\"]\n val = a\\\\\n ue = b\n\nand saw \"git config --rename-section sec.tio sec.tion\" just work\nfine (without the event stream change). Without the event stream\nchange, \"git config --unset sec.tio.ue\" loses \"sec.tio.val\" but with\nit we see we only lose the last line, which is the correct thing to\nhappen.\n\nNice.\n"}]}