{"thread":{"id":"32602","subject":"[BUG] Possible bug in `remote set-url --add --push`","startedAt":"2013-01-12T05:44:25Z","lastAt":"2013-01-16T20:01:25Z","messageCount":27,"participants":["Jardel Weyrich","Junio C Hamano","Sascha Cunz","Michael J Gruber","Jonathan Nieder","John Keeping","Phil Hord","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"206577","messageId":"CAN8TAOsnX1Mr72LPa47KKXDeUZPgSHTJ6u4YpPFPrtsK7VdN+A@mail.gmail.com","threadId":"32602","inReplyTo":null,"subject":"[BUG] Possible bug in `remote set-url --add --push`","fromName":"Jardel Weyrich","fromEmail":"jweyrich@gmail.com","sentAt":"2013-01-12T05:44:25Z","receivedAt":"2013-01-12T05:44:25Z","isPatch":false,"sender":{"key":"jweyrich@gmail.com","avatar":"https://gravatar.com/avatar/a267a3d13e69d03a95833d518845af8595ac6c64b7030ce5eb9f18c19a5c07d5?d=mp&s=160"},"body":"Hi,\n\nI believe `remote set-url --add --push` has a bug. Performed tests\nwith v1.8.0.1 and v1.8.1 (Mac OS X).\n\nQuoting the relevant part of the documentation:\n\n> set-url\n> Changes URL remote points to. Sets first URL remote points to matching regex (first URL if no is given) to . If doesn’t match any URL, error occurs and nothing is changed.\n>\n> With --push, push URLs are manipulated instead of fetch URLs.\n> With --add, instead of changing some URL, new URL is added.\n> With --delete, instead of changing some URL, all URLs matching regex are deleted. Trying to delete all non-push URLs is an error.\n\nHere are some steps to reproduce:\n\n1. Show the remote URLs\n\njweyrich@pharao:test_clone1 [* master]$ git remote -v\norigin /Volumes/sandbox/test (fetch)\norigin /Volumes/sandbox/test (push)\n\n2. Add a new push URL for origin\n\njweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \\\n /Volumes/sandbox/test_clone2\n\n3. Check what happened\n\njweyrich@pharao:test_clone1 [* master]$ git remote -v\norigin /Volumes/sandbox/test (fetch)\norigin /Volumes/sandbox/test_clone2 (push)\n\n4. Missing an URL? Re-add the original one\n\njweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \\\n /Volumes/sandbox/test\n\n5. Check what happened, again\n\njweyrich@pharao:test_clone1 [* master]$ git remote -v\norigin /Volumes/sandbox/test (fetch)\norigin /Volumes/sandbox/test_clone2 (push)\norigin /Volumes/sandbox/test (push)\n\nIn step 2, Git replaced the original push URL instead of adding a new\none. But it seems to happen only the first time I use `remote set-url\n--add --push`. Re-adding the original URL using the same command seems\nto work properly.\nAnd FWIW, if I delete (with \"set-url --delete\") both URLs push, Git\nrestores the original URL.\n\nPlease, could someone try to reproduce?\n\n- jw\n"},{"id":"206588","messageId":"7vliby98r7.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"CAN8TAOsnX1Mr72LPa47KKXDeUZPgSHTJ6u4YpPFPrtsK7VdN+A@mail.gmail.com","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-12T07:10:36Z","receivedAt":"2013-01-12T07:10:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jardel Weyrich writes:\n\n> I believe `remote set-url --add --push` has a bug. Performed tests\n> with v1.8.0.1 and v1.8.1 (Mac OS X).\n>\n> Quoting the relevant part of the documentation:\n>\n>> set-url\n>> Changes URL remote points to. Sets first URL remote points to matching regex (first URL if no is given) to . If doesn’t match any URL, error occurs and nothing is changed.\n>>\n>> With --push, push URLs are manipulated instead of fetch URLs.\n>> With --add, instead of changing some URL, new URL is added.\n>> With --delete, instead of changing some URL, all URLs matching regex are deleted. Trying to delete all non-push URLs is an error.\n>\n> Here are some steps to reproduce:\n>\n> 1. Show the remote URLs\n>\n> jweyrich@pharao:test_clone1 [* master]$ git remote -v\n> origin /Volumes/sandbox/test (fetch)\n> origin /Volumes/sandbox/test (push)\n>\n> 2. Add a new push URL for origin\n>\n> jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \\\n> /Volumes/sandbox/test_clone2\n>\n> 3. Check what happened\n>\n> jweyrich@pharao:test_clone1 [* master]$ git remote -v\n> origin /Volumes/sandbox/test (fetch)\n> origin /Volumes/sandbox/test_clone2 (push)\n\nThe original pushurl was replaced with the additional one, instead\nof being left and the new one getting added. That looks certainly\nwrong.\n\nHowever, the result of applying the attached patch (either to\nv1.7.12 or v1.8.1) still passes the test and I do not think it is\ndoing anything differently from what you described above.\n\nWhat do you get from\n\n\tgit config -l | grep '^remote\\.origin'\n\nin steps 1. and 3. in your procedure? This question is trying to\ntell if your bug is in \"git remote -v\" or in \"git remote set-url\".\n\n-- >8 --\nFrom 0f6cbc67db926e97707ae732b02e790b4604508e Mon Sep 17 00:00:00 2001\nFrom: Junio C Hamano \nDate: Fri, 11 Jan 2013 23:04:16 -0800\nSubject: [PATCH] t5505: adding one pushurl from jweyrich\n\nSigned-off-by: Junio C Hamano \n---\n t/t5505-remote.sh | 19 +++++++++++++++++++\n 1 file changed, 19 insertions(+)\n\ndiff --git a/t/t5505-remote.sh b/t/t5505-remote.sh\nindex c03ffdd..b31c5bb 100755\n--- a/t/t5505-remote.sh\n+++ b/t/t5505-remote.sh\n@@ -901,6 +901,25 @@ test_expect_success 'remote set-url --push --add aaa' '\n \tcmp expect actual\n '\n \n+test_expect_success 'remote set-url --push --add' '\n+\tgit config remote.jweyrich.url /Volumes/sandbox/test &&\n+\tgit config remote.jweyrich.pushurl /Volumes/sandbox/test &&\n+\tgit config remote.jweyrich.fetch \"refs/heads/*:refs/remotes/jweyrich/*\" &&\n+\n+\tadded=/Volumes/sandbox/test_clone2 &&\n+\t{\n+\t\tgit config -l | grep \"^remote\\.jweyrich\\.\" &&\n+\t\techo \"remote.jweyrich.pushurl=$added\"\n+\t} | sort >expect &&\n+\n+\tgit remote set-url --add --push jweyrich \"$added\" &&\n+\tgit config -l | grep \"^remote\\.jweyrich\\.\" | sort >actual &&\n+\n+\ttest_cmp expect actual &&\n+\n+\tgit remote -v | grep \"^jweyrich\" # this is just for debugging\n+'\n+\n test_expect_success 'remote set-url --push bar aaa' '\n \tgit remote set-url --push someremote bar aaa &&\n \techo foo >expect &&\n-- \n1.8.1.421.g6236851\n"},{"id":"206589","messageId":"CAN8TAOvP_HX6BEK86aYoX-kVqWDmsbyptxTT2nk+fx+Ut1Tojg@mail.gmail.com","threadId":"32602","inReplyTo":"7vliby98r7.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Jardel Weyrich","fromEmail":"jweyrich@gmail.com","sentAt":"2013-01-12T08:09:35Z","receivedAt":"2013-01-12T08:09:35Z","isPatch":false,"sender":{"key":"jweyrich@gmail.com","avatar":"https://gravatar.com/avatar/a267a3d13e69d03a95833d518845af8595ac6c64b7030ce5eb9f18c19a5c07d5?d=mp&s=160"},"body":"Step 1:\n\njweyrich@pharao:test_clone1 [* master]$ git remote -v\norigin /Volumes/sandbox/test (fetch)\norigin /Volumes/sandbox/test (push)\n\njweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\\.origin'\nremote.origin.url=/Volumes/sandbox/test\nremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\n\nStep 3:\n\njweyrich@pharao:test_clone1 [* master]$ git remote set-url --add\n--push origin /Volumes/sandbox/test_clone2\norigin /Volumes/sandbox/test (fetch)\norigin /Volumes/sandbox/test_clone2/ (push)\n\njweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\\.origin'\nremote.origin.url=/Volumes/sandbox/test\nremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\nremote.origin.pushurl=/Volumes/sandbox/test_clone2/\n\n\nAfter that, if I do a commit in test_clone1 and try to push to origin,\nit pushes only to the test_clone2 rather than pushing to both test and\ntest_clone2 (it's a bare repo, sorry for using a misleading name).\n\nIs `remote..pushurl` required for the primary URL as\nwell? If not, then git-push is not handling that information as it\nshould.\n\nOn Sat, Jan 12, 2013 at 5:10 AM, Junio C Hamano wrote:\n> Jardel Weyrich writes:\n>\n>> I believe `remote set-url --add --push` has a bug. Performed tests\n>> with v1.8.0.1 and v1.8.1 (Mac OS X).\n>>\n>> Quoting the relevant part of the documentation:\n>>\n>>> set-url\n>>> Changes URL remote points to. Sets first URL remote points to matching regex (first URL if no is given) to . If doesn’t match any URL, error occurs and nothing is changed.\n>>>\n>>> With --push, push URLs are manipulated instead of fetch URLs.\n>>> With --add, instead of changing some URL, new URL is added.\n>>> With --delete, instead of changing some URL, all URLs matching regex are deleted. Trying to delete all non-push URLs is an error.\n>>\n>> Here are some steps to reproduce:\n>>\n>> 1. Show the remote URLs\n>>\n>> jweyrich@pharao:test_clone1 [* master]$ git remote -v\n>> origin /Volumes/sandbox/test (fetch)\n>> origin /Volumes/sandbox/test (push)\n>>\n>> 2. Add a new push URL for origin\n>>\n>> jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push origin \\\n>> /Volumes/sandbox/test_clone2\n>>\n>> 3. Check what happened\n>>\n>> jweyrich@pharao:test_clone1 [* master]$ git remote -v\n>> origin /Volumes/sandbox/test (fetch)\n>> origin /Volumes/sandbox/test_clone2 (push)\n>\n> The original pushurl was replaced with the additional one, instead\n> of being left and the new one getting added. That looks certainly\n> wrong.\n>\n> However, the result of applying the attached patch (either to\n> v1.7.12 or v1.8.1) still passes the test and I do not think it is\n> doing anything differently from what you described above.\n>\n> What do you get from\n>\n> git config -l | grep '^remote\\.origin'\n>\n> in steps 1. and 3. in your procedure? This question is trying to\n> tell if your bug is in \"git remote -v\" or in \"git remote set-url\".\n>\n> -- >8 --\n> From 0f6cbc67db926e97707ae732b02e790b4604508e Mon Sep 17 00:00:00 2001\n> From: Junio C Hamano \n> Date: Fri, 11 Jan 2013 23:04:16 -0800\n> Subject: [PATCH] t5505: adding one pushurl from jweyrich\n>\n> Signed-off-by: Junio C Hamano \n> ---\n> t/t5505-remote.sh | 19 +++++++++++++++++++\n> 1 file changed, 19 insertions(+)\n>\n> diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh\n> index c03ffdd..b31c5bb 100755\n> --- a/t/t5505-remote.sh\n> +++ b/t/t5505-remote.sh\n> @@ -901,6 +901,25 @@ test_expect_success 'remote set-url --push --add aaa' '\n> cmp expect actual\n> '\n>\n> +test_expect_success 'remote set-url --push --add' '\n> + git config remote.jweyrich.url /Volumes/sandbox/test &&\n> + git config remote.jweyrich.pushurl /Volumes/sandbox/test &&\n> + git config remote.jweyrich.fetch \"refs/heads/*:refs/remotes/jweyrich/*\" &&\n> +\n> + added=/Volumes/sandbox/test_clone2 &&\n> + {\n> + git config -l | grep \"^remote\\.jweyrich\\.\" &&\n> + echo \"remote.jweyrich.pushurl=$added\"\n> + } | sort >expect &&\n> +\n> + git remote set-url --add --push jweyrich \"$added\" &&\n> + git config -l | grep \"^remote\\.jweyrich\\.\" | sort >actual &&\n> +\n> + test_cmp expect actual &&\n> +\n> + git remote -v | grep \"^jweyrich\" # this is just for debugging\n> +'\n> +\n> test_expect_success 'remote set-url --push bar aaa' '\n> git remote set-url --push someremote bar aaa &&\n> echo foo >expect &&\n> --\n> 1.8.1.421.g6236851\n"},{"id":"206590","messageId":"7vpq1aizck.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"CAN8TAOvP_HX6BEK86aYoX-kVqWDmsbyptxTT2nk+fx+Ut1Tojg@mail.gmail.com","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-12T08:23:39Z","receivedAt":"2013-01-12T08:23:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jardel Weyrich writes:\n\n> Step 1:\n>\n> jweyrich@pharao:test_clone1 [* master]$ git remote -v\n> origin /Volumes/sandbox/test (fetch)\n> origin /Volumes/sandbox/test (push)\n>\n> jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\\.origin'\n> remote.origin.url=/Volumes/sandbox/test\n> remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\n>\n> Step 3:\n>\n> jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add\n> --push origin /Volumes/sandbox/test_clone2\n> origin /Volumes/sandbox/test (fetch)\n> origin /Volumes/sandbox/test_clone2/ (push)\n>\n> jweyrich@pharao:test_clone1 [* master]$ git config -l | grep '^remote\\.origin'\n> remote.origin.url=/Volumes/sandbox/test\n> remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*\n> remote.origin.pushurl=/Volumes/sandbox/test_clone2/\n\nSo \"remote -v\" is not lying (we only see one pushurl after Step 3\nabove) and \"set-url\" is not working correctly on your box in a way\nthat I cannot reproduce X-<.\n\n> ...\n> Is `remote..pushurl` required for the primary URL as\n> well?\n\nWhat do you mean by \"primary URL\"?\n"},{"id":"206592","messageId":"4836187.09xoy3kJnj@blacky","threadId":"32602","inReplyTo":"7vliby98r7.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Sascha Cunz","fromEmail":"sascha-ml@babbelbox.org","sentAt":"2013-01-12T08:44:00Z","receivedAt":"2013-01-12T08:44:00Z","isPatch":false,"sender":{"key":"sascha-ml@babbelbox.org","avatar":null},"body":"Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:\n> Jardel Weyrich writes:\n> > I believe `remote set-url --add --push` has a bug. Performed tests\n> > with v1.8.0.1 and v1.8.1 (Mac OS X).\n> > \n> > Quoting the relevant part of the documentation:\n> >> set-url\n> >> \n> >> Changes URL remote points to. Sets first URL remote points to\n> >> matching regex (first URL if no is given) to\n> >> . If doesn’t match any URL, error occurs and\n> >> nothing is changed.\n> >> \n> >> With --push, push URLs are manipulated instead of fetch URLs.\n> >> With --add, instead of changing some URL, new URL is added.\n> >> With --delete, instead of changing some URL, all URLs matching regex\n> >> are deleted. Trying to delete all non-push URLs is an error.> \n> > Here are some steps to reproduce:\n> > \n> > 1. Show the remote URLs\n> > \n> > jweyrich@pharao:test_clone1 [* master]$ git remote -v\n> > origin /Volumes/sandbox/test (fetch)\n> > origin /Volumes/sandbox/test (push)\n> > \n> > 2. Add a new push URL for origin\n> > \n> > jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push\n> > origin \\> \n> > /Volumes/sandbox/test_clone2\n> > \n> > 3. Check what happened\n> > \n> > jweyrich@pharao:test_clone1 [* master]$ git remote -v\n> > origin /Volumes/sandbox/test (fetch)\n> > origin /Volumes/sandbox/test_clone2 (push)\n> \n> The original pushurl was replaced with the additional one, instead\n> of being left and the new one getting added. That looks certainly\n> wrong.\n> \n> However, the result of applying the attached patch (either to\n> v1.7.12 or v1.8.1) still passes the test and I do not think it is\n> doing anything differently from what you described above.\n> \n> What do you get from\n> \n> \tgit config -l | grep '^remote\\.origin'\n> \n> in steps 1. and 3. in your procedure? This question is trying to\n> tell if your bug is in \"git remote -v\" or in \"git remote set-url\".\n\nI'm not sure, if there is a bug at all. According to man git-push:\n\n\tThe is used for pushes only. It is optional and defaults to\n .\n\t(From the section REMOTES -> Named remote in configuration file)\n\nthe command:\n git remote add foo git@foo-fetch.org/some.git\n\nwill set \"remote.foo.url\" to \"git@foo-fetch.org\". Subsequently, fetch and push \nwill use git@foo-fetch.org as url.\nFetch will use this url, because \"remote.foo.url\" explicitly sets this. push \nwill use it in absence of a \"remote.foo.pushurl\".\n\nNow, we're adding a push-url:\n git remote set-url --add --push foo git@foo-push.org/some.git\n\nRelevant parts of config are now looking like:\n\t[remote \"foo\"]\n url = git@foo-fetch.org/some.git\n pushurl = git@foo-push.org/some.git\n\nSince, pushurl is now given explicitly, git push will use that one (and only \nthat one).\n\nIf we add another push-url now,\n git remote set-url --add --push foo git@foo-push-also.org/some.git\n\nthe next git-push will push to foo-push.org and foo-push-also.org.\n\nNow, using --set-url --delete on both of these urls restores the original \nstate: only \"remote.foo.url\" is set; meaning implicitly pushurl defaults to \nurl again.\n\nTo me this is exactly what Jardel was observing:\n\n> In step 2, Git replaced the original push URL instead of adding a new\n> one. But it seems to happen only the first time I use `remote set-url\n> --add --push`. Re-adding the original URL using the same command seems\n> to work properly.\n\n> And FWIW, if I delete (with \"set-url --delete\") both URLs push, Git\n> restores the original URL.\n\nOr am I missing something here?\n\nMight be that the \"bug\" actually is that the expectation was\n\n\tgit remote add foo git@foo-fetch.org/some.git\n\nshould have created a config like:\n\n\t[remote \"foo\"]\n url = git@foo-fetch.org/some.git\n pushurl = git@foo-fetch.org/some.git\n\nsince that is what \"git remote -v\" reports.\n\nIf that is the case, we might want to amend the output of 'git remote -v' with \nthe information that a pushurl is not explicitly given and thus defaults to \nurl.\n\nSascha\n"},{"id":"206593","messageId":"CAN8TAOv0Cm8CgiJSweFtRzOqO78OtNKa4G+x7z6M5Bt+odUmiQ@mail.gmail.com","threadId":"32602","inReplyTo":"4836187.09xoy3kJnj@blacky","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Jardel Weyrich","fromEmail":"jweyrich@gmail.com","sentAt":"2013-01-12T09:33:22Z","receivedAt":"2013-01-12T09:33:22Z","isPatch":false,"sender":{"key":"jweyrich@gmail.com","avatar":"https://gravatar.com/avatar/a267a3d13e69d03a95833d518845af8595ac6c64b7030ce5eb9f18c19a5c07d5?d=mp&s=160"},"body":"On Sat, Jan 12, 2013 at 6:44 AM, Sascha Cunz wrote:\n> Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:\n>> Jardel Weyrich writes:\n>> > I believe `remote set-url --add --push` has a bug. Performed tests\n>> > with v1.8.0.1 and v1.8.1 (Mac OS X).\n>> >\n>> > Quoting the relevant part of the documentation:\n>> >> set-url\n>> >>\n>> >> Changes URL remote points to. Sets first URL remote points to\n>> >> matching regex (first URL if no is given) to\n>> >> . If doesn’t match any URL, error occurs and\n>> >> nothing is changed.\n>> >>\n>> >> With --push, push URLs are manipulated instead of fetch URLs.\n>> >> With --add, instead of changing some URL, new URL is added.\n>> >> With --delete, instead of changing some URL, all URLs matching regex\n>> >> are deleted. Trying to delete all non-push URLs is an error.>\n>> > Here are some steps to reproduce:\n>> >\n>> > 1. Show the remote URLs\n>> >\n>> > jweyrich@pharao:test_clone1 [* master]$ git remote -v\n>> > origin /Volumes/sandbox/test (fetch)\n>> > origin /Volumes/sandbox/test (push)\n>> >\n>> > 2. Add a new push URL for origin\n>> >\n>> > jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push\n>> > origin \\>\n>> > /Volumes/sandbox/test_clone2\n>> >\n>> > 3. Check what happened\n>> >\n>> > jweyrich@pharao:test_clone1 [* master]$ git remote -v\n>> > origin /Volumes/sandbox/test (fetch)\n>> > origin /Volumes/sandbox/test_clone2 (push)\n>>\n>> The original pushurl was replaced with the additional one, instead\n>> of being left and the new one getting added. That looks certainly\n>> wrong.\n>>\n>> However, the result of applying the attached patch (either to\n>> v1.7.12 or v1.8.1) still passes the test and I do not think it is\n>> doing anything differently from what you described above.\n>>\n>> What do you get from\n>>\n>> git config -l | grep '^remote\\.origin'\n>>\n>> in steps 1. and 3. in your procedure? This question is trying to\n>> tell if your bug is in \"git remote -v\" or in \"git remote set-url\".\n>\n> I'm not sure, if there is a bug at all. According to man git-push:\n>\n> The is used for pushes only. It is optional and defaults to\n> .\n> (From the section REMOTES -> Named remote in configuration file)\n>\n> the command:\n> git remote add foo git@foo-fetch.org/some.git\n>\n> will set \"remote.foo.url\" to \"git@foo-fetch.org\". Subsequently, fetch and push\n> will use git@foo-fetch.org as url.\n> Fetch will use this url, because \"remote.foo.url\" explicitly sets this. push\n> will use it in absence of a \"remote.foo.pushurl\".\n>\n> Now, we're adding a push-url:\n> git remote set-url --add --push foo git@foo-push.org/some.git\n>\n> Relevant parts of config are now looking like:\n> [remote \"foo\"]\n> url = git@foo-fetch.org/some.git\n> pushurl = git@foo-push.org/some.git\n>\n> Since, pushurl is now given explicitly, git push will use that one (and only\n> that one).\n>\n> If we add another push-url now,\n> git remote set-url --add --push foo git@foo-push-also.org/some.git\n>\n> the next git-push will push to foo-push.org and foo-push-also.org.\n>\n> Now, using --set-url --delete on both of these urls restores the original\n> state: only \"remote.foo.url\" is set; meaning implicitly pushurl defaults to\n> url again.\n>\n> To me this is exactly what Jardel was observing:\n>\n>> In step 2, Git replaced the original push URL instead of adding a new\n>> one. But it seems to happen only the first time I use `remote set-url\n>> --add --push`. Re-adding the original URL using the same command seems\n>> to work properly.\n>\n>> And FWIW, if I delete (with \"set-url --delete\") both URLs push, Git\n>> restores the original URL.\n>\n> Or am I missing something here?\n\nYou're right. However, as I quoted earlier, the git-remote man-page states:\n\n set-url\n Changes URL remote points to. \n With --push, push URLs are manipulated instead of fetch URLs.\n With --add, instead of changing some URL, new URL is added.\n\nIt explicitly mentions that it should **add a new URL**.\nSo when I do `git remote set-url --add --push origin\ngit://another/repo.git`, I expect git-push to use both the default\npush URL and the new one. Or am I misinterpreting the man-page?\n\n>\n> Might be that the \"bug\" actually is that the expectation was\n>\n> git remote add foo git@foo-fetch.org/some.git\n>\n> should have created a config like:\n>\n> [remote \"foo\"]\n> url = git@foo-fetch.org/some.git\n> pushurl = git@foo-fetch.org/some.git\n>\n> since that is what \"git remote -v\" reports.\n>\n> If that is the case, we might want to amend the output of 'git remote -v' with\n> the information that a pushurl is not explicitly given and thus defaults to\n> url.\n\nCorrect. Adding a remote doesn't automatically generate a pushurl for it.\n\nTo me, it seems that git-push checks for the existence of pushurl's in\nthe config, and if it finds any, it ignores the defaul push URL during\nthe actual push. In better words, it pushes only to pushurls, if it\nfinds any, otherwise it pushes to the default URL.\n\nTo comply with the statements in the git-remote man-page, git-remote\nshould add a pushurl configuration containing the default push URL,\nalong with the one passed to `set-url --add --push`. Or git-push\nshould _not ignore_ the default URL in the presence of pushurls,\neffectively pushing to both. These are the solutions I can think of\nright now, supposing I'm correct about the cause(s).\n\n>\n> Sascha\n"},{"id":"206796","messageId":"50F40316.7010308@drmicha.warpmail.net","threadId":"32602","inReplyTo":"CAN8TAOv0Cm8CgiJSweFtRzOqO78OtNKa4G+x7z6M5Bt+odUmiQ@mail.gmail.com","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-14T13:07:34Z","receivedAt":"2013-01-14T13:07:34Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jardel Weyrich venit, vidit, dixit 12.01.2013 10:33:\n> On Sat, Jan 12, 2013 at 6:44 AM, Sascha Cunz wrote:\n>> Am Freitag, 11. Januar 2013, 23:10:36 schrieb Junio C Hamano:\n>>> Jardel Weyrich writes:\n>>>> I believe `remote set-url --add --push` has a bug. Performed tests\n>>>> with v1.8.0.1 and v1.8.1 (Mac OS X).\n>>>>\n>>>> Quoting the relevant part of the documentation:\n>>>>> set-url\n>>>>>\n>>>>> Changes URL remote points to. Sets first URL remote points to\n>>>>> matching regex (first URL if no is given) to\n>>>>> . If doesn’t match any URL, error occurs and\n>>>>> nothing is changed.\n>>>>>\n>>>>> With --push, push URLs are manipulated instead of fetch URLs.\n>>>>> With --add, instead of changing some URL, new URL is added.\n>>>>> With --delete, instead of changing some URL, all URLs matching regex\n>>>>> are deleted. Trying to delete all non-push URLs is an error.>\n>>>> Here are some steps to reproduce:\n>>>>\n>>>> 1. Show the remote URLs\n>>>>\n>>>> jweyrich@pharao:test_clone1 [* master]$ git remote -v\n>>>> origin /Volumes/sandbox/test (fetch)\n>>>> origin /Volumes/sandbox/test (push)\n>>>>\n>>>> 2. Add a new push URL for origin\n>>>>\n>>>> jweyrich@pharao:test_clone1 [* master]$ git remote set-url --add --push\n>>>> origin \\>\n>>>> /Volumes/sandbox/test_clone2\n>>>>\n>>>> 3. Check what happened\n>>>>\n>>>> jweyrich@pharao:test_clone1 [* master]$ git remote -v\n>>>> origin /Volumes/sandbox/test (fetch)\n>>>> origin /Volumes/sandbox/test_clone2 (push)\n>>>\n>>> The original pushurl was replaced with the additional one, instead\n>>> of being left and the new one getting added. That looks certainly\n>>> wrong.\n>>>\n>>> However, the result of applying the attached patch (either to\n>>> v1.7.12 or v1.8.1) still passes the test and I do not think it is\n>>> doing anything differently from what you described above.\n>>>\n>>> What do you get from\n>>>\n>>> git config -l | grep '^remote\\.origin'\n>>>\n>>> in steps 1. and 3. in your procedure? This question is trying to\n>>> tell if your bug is in \"git remote -v\" or in \"git remote set-url\".\n>>\n>> I'm not sure, if there is a bug at all. According to man git-push:\n>>\n>> The is used for pushes only. It is optional and defaults to\n>> .\n>> (From the section REMOTES -> Named remote in configuration file)\n>>\n>> the command:\n>> git remote add foo git@foo-fetch.org/some.git\n>>\n>> will set \"remote.foo.url\" to \"git@foo-fetch.org\". Subsequently, fetch and push\n>> will use git@foo-fetch.org as url.\n>> Fetch will use this url, because \"remote.foo.url\" explicitly sets this. push\n>> will use it in absence of a \"remote.foo.pushurl\".\n>>\n>> Now, we're adding a push-url:\n>> git remote set-url --add --push foo git@foo-push.org/some.git\n>>\n>> Relevant parts of config are now looking like:\n>> [remote \"foo\"]\n>> url = git@foo-fetch.org/some.git\n>> pushurl = git@foo-push.org/some.git\n>>\n>> Since, pushurl is now given explicitly, git push will use that one (and only\n>> that one).\n>>\n>> If we add another push-url now,\n>> git remote set-url --add --push foo git@foo-push-also.org/some.git\n>>\n>> the next git-push will push to foo-push.org and foo-push-also.org.\n>>\n>> Now, using --set-url --delete on both of these urls restores the original\n>> state: only \"remote.foo.url\" is set; meaning implicitly pushurl defaults to\n>> url again.\n>>\n>> To me this is exactly what Jardel was observing:\n>>\n>>> In step 2, Git replaced the original push URL instead of adding a new\n>>> one. But it seems to happen only the first time I use `remote set-url\n>>> --add --push`. Re-adding the original URL using the same command seems\n>>> to work properly.\n>>\n>>> And FWIW, if I delete (with \"set-url --delete\") both URLs push, Git\n>>> restores the original URL.\n>>\n>> Or am I missing something here?\n> \n> You're right. However, as I quoted earlier, the git-remote man-page states:\n> \n> set-url\n> Changes URL remote points to. \n> With --push, push URLs are manipulated instead of fetch URLs.\n> With --add, instead of changing some URL, new URL is added.\n> \n> It explicitly mentions that it should **add a new URL**.\n> So when I do `git remote set-url --add --push origin\n> git://another/repo.git`, I expect git-push to use both the default\n> push URL and the new one. Or am I misinterpreting the man-page?\n> \n>>\n>> Might be that the \"bug\" actually is that the expectation was\n>>\n>> git remote add foo git@foo-fetch.org/some.git\n>>\n>> should have created a config like:\n>>\n>> [remote \"foo\"]\n>> url = git@foo-fetch.org/some.git\n>> pushurl = git@foo-fetch.org/some.git\n>>\n>> since that is what \"git remote -v\" reports.\n>>\n>> If that is the case, we might want to amend the output of 'git remote -v' with\n>> the information that a pushurl is not explicitly given and thus defaults to\n>> url.\n> \n> Correct. Adding a remote doesn't automatically generate a pushurl for it.\n> \n> To me, it seems that git-push checks for the existence of pushurl's in\n> the config, and if it finds any, it ignores the defaul push URL during\n> the actual push. In better words, it pushes only to pushurls, if it\n> finds any, otherwise it pushes to the default URL.\n> \n> To comply with the statements in the git-remote man-page, git-remote\n> should add a pushurl configuration containing the default push URL,\n> along with the one passed to `set-url --add --push`. Or git-push\n> should _not ignore_ the default URL in the presence of pushurls,\n> effectively pushing to both. These are the solutions I can think of\n> right now, supposing I'm correct about the cause(s).\n> \n>>\n>> Sascha\n\nAll that \"set-url --push --add\" does is adding a remote.foo.pushurl\nentry to the config. If there was none, there will be one after that.\n\nIf there is no pushurl entry, \"push\" takes the url entry instead. This\nis the \"default URL for push\", but not a pushurl entry.\n\nIt seems to me that everything works as designed, and that the man page\ntalk about \"push URLs\" can be read in two ways, one of which is correct\n(and which is obvious if you know the above, i.e. the \"config\nbackground\") and one of which is incorrect (and which may be obvious if\nyou read just that man page paragraph).\n\nMichael\n"},{"id":"206808","messageId":"20130114164114.GA3121@elie.Belkin","threadId":"32602","inReplyTo":"50F40316.7010308@drmicha.warpmail.net","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-01-14T16:41:14Z","receivedAt":"2013-01-14T16:41:14Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael J Gruber wrote:\n\n> All that \"set-url --push --add\" does is adding a remote.foo.pushurl\n> entry to the config. If there was none, there will be one after that.\n>\n> If there is no pushurl entry, \"push\" takes the url entry instead. This\n> is the \"default URL for push\", but not a pushurl entry.\n\nThat is how it is implemented, but it is hard for me with a straight\nface to say that is what most users expect.\n\nWouldn't the least confusing thing be to just error out for \"set-url\n--push --add\" when there is no existing pushurl? That way, the\noperator can use plain \"set-url --push\" to clarify whether whether he\nmeant to include the pull URLs in the new pushurl set.\n\nMy two cents,\nJonathan\n"},{"id":"206826","messageId":"7v1udnbmyz.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"50F40316.7010308@drmicha.warpmail.net","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-14T19:09:40Z","receivedAt":"2013-01-14T19:09:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> It seems to me that everything works as designed, and that the man page\n> talk about \"push URLs\" can be read in two ways,...\n\nHmph, but I had an impression that Jardel's original report was that\none of the --add --pushurl was not adding but was replacing. If\nthat was a false alarm, everything you said makes sense to me.\n\nThanks.\n"},{"id":"206883","messageId":"1D472234-A0A5-4F02-878D-D05DEE995FCD@gmail.com","threadId":"32602","inReplyTo":"7v1udnbmyz.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Jardel Weyrich","fromEmail":"jweyrich@gmail.com","sentAt":"2013-01-15T05:20:53Z","receivedAt":"2013-01-15T05:20:53Z","isPatch":false,"sender":{"key":"jweyrich@gmail.com","avatar":"https://gravatar.com/avatar/a267a3d13e69d03a95833d518845af8595ac6c64b7030ce5eb9f18c19a5c07d5?d=mp&s=160"},"body":"On 14/01/2013, at 17:09, Junio C Hamano wrote:\n\n> Michael J Gruber writes:\n> \n>> It seems to me that everything works as designed, and that the man page\n>> talk about \"push URLs\" can be read in two ways,...\n> \n> Hmph, but I had an impression that Jardel's original report was that\n> one of the --add --pushurl was not adding but was replacing. If\n> that was a false alarm, everything you said makes sense to me.\n> \n> Thanks.\n\nI failed to explain my reasoning. But I learned quite a bit from this discussion. I understood that the defaul push url is not used by git-push when there's at least one pushurl for a given remote.\n\nIf that's by design, I still fail to comprehend the exact reason.\nIf you allow me, I'd like you to forget about the concepts for a minute, and focus on the user experience.\nImagine a simple hypothetical scenario in which the user wants to push to 2 distinct repositories. He already has cloned the repo from the 1st repository, thus (theoretically) all he needs to do, is to add a new repository for push. He then uses `remote set-url --add --push <2nd-repo>` (which I personally thought would suffice). However, if he tries to push a new commit to this remote, it would be pushed _only_ to the 2nd-repo.\n\nThis is exactly what I thought to be a bug. If it's intended to work the way I described in the previous scenario, I'll have to ask and/or research to understand the reason behind this -- Why does having a pushurl make git-push _not_ to push to the default push location (the 1st repo in my scenario) as well? Could you describe a scenario in which that behavior is useful and/or better than the behavior I expected?\n\nPlease, pardon me for not being as clear as needed. I appreciate your time on this. Thank you all.\n\nSent from my mobile."},{"id":"206906","messageId":"7vpq1755jb.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"1D472234-A0A5-4F02-878D-D05DEE995FCD@gmail.com","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-15T06:22:48Z","receivedAt":"2013-01-15T06:22:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jardel Weyrich writes:\n\n> If you allow me, I'd like you to forget about the concepts for a minute, and focus on the user experience.\n> Imagine a simple hypothetical scenario in which the user wants to push to 2 distinct repositories. He already has cloned the repo from the 1st repository, thus (theoretically) all he needs to do, is to add a new repository for push. He then uses `remote set-url --add --push <2nd-repo>` (which I personally thought would suffice). However, if he tries to push a new commit to this remote, it would be pushed _only_ to the 2nd-repo.\n\nThe primary reason behind push-url was that\n\n (1) usually you push to and fetch from the same, so no pushUrl is\n ever needed, just a single Url will do (this is often true for\n cvs/svn style shared repository workflow); and\n\n (2) sometimes you want to fetch from one place and push to another\n (this is often true for \"fetch from upstream, push to my own\n and ask upstream to pull from it\" workflow), and in that case\n you want pushUrl in addition to Url. Most importantly, in this\n case, you do *NOT* want to push to Url. You only push to\n pushUrl.\n\nSetting *one* pushURL is a way to say \"That URL I fetch from is\n*not* the place I want to push (I may not even be able to push\nthere); when I say 'push', push there instead\". Your proposed\nsemantics will make it impossible to arrange such an asymmetric\nsetting.\n"},{"id":"206907","messageId":"7vip6z54rh.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"7vpq1755jb.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-15T06:39:30Z","receivedAt":"2013-01-15T06:39:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jardel Weyrich writes:\n>\n>> If you allow me, I'd like you to forget about the concepts for a minute, and focus on the user experience.\n>> Imagine a simple hypothetical scenario in which the user wants to push to 2 distinct repositories. He already has cloned the repo from the 1st repository, thus (theoretically) all he needs to do, is to add a new repository for push. He then uses `remote set-url --add --push <2nd-repo>` (which I personally thought would suffice). However, if he tries to push a new commit to this remote, it would be pushed _only_ to the 2nd-repo.\n>\n> The primary reason behind push-url was that\n>\n> (1) usually you push to and fetch from the same, so no pushUrl is\n> ever needed, just a single Url will do (this is often true for\n> cvs/svn style shared repository workflow); and\n>\n> (2) sometimes you want to fetch from one place and push to another\n> (this is often true for \"fetch from upstream, push to my own\n> and ask upstream to pull from it\" workflow), and in that case\n> you want pushUrl in addition to Url. Most importantly, in this\n> case, you do *NOT* want to push to Url. You only push to\n> pushUrl.\n>\n> Setting *one* pushURL is a way to say \"That URL I fetch from is\n> *not* the place I want to push (I may not even be able to push\n> there); when I say 'push', push there instead\". Your proposed\n> semantics will make it impossible to arrange such an asymmetric\n> setting.\n\nNow I think I finally see where that misunderstanding comes from.\nIt is \"remote -v\" that is misdesigned.\n\n $ git clone ../there here\n $ cd here\n $ git remote -v\n origin /var/tmp/there (fetch)\n origin /var/tmp/there (push)\n\nThis is totally bogus. It should report something like this:\n\n $ git remote -v\n origin /var/tmp/there (fetch/push)\n\nThen after running \"git remote set-url --push origin ../another\" we\nshould see\n\n $ git remote -v\n origin /var/tmp/there (fetch)\n origin /var/tmp/another (push)\n\nwhich would make it clear that the original fetch/push came from the\n(1) usuall you push and fetch from the same place so there is only\none setting, and the two lines came from the (2) sometimes you need\na separate places to fetch from and push to.\n\nAt this point, if you say \"set-url --push origin ../third\", then\n\"another\" will disappear and gets replaced by \"third\"; if you\ninstead say \"set-url --add --push origin ../third\", then we will see\ntwo (push) lines, in addition to one (fetch), making it clear that\nyou are still in (2) above, fetching from and pushing to different\nplaces, and having two places to push to.\n\nI misread your response\n\n From: Jardel Weyrich \n Subject: Re: [BUG] Possible bug in `remote set-url --add --push`\n Date: Sat, 12 Jan 2013 06:09:35 -0200\n Message-ID: \n\nwhere you showed that there was only remote.origin.url (and no\npushurl) in the first step, and somehow thought you had a\nremote.origin.pushurl in the first place.\n"},{"id":"206928","messageId":"50F524F8.5090803@drmicha.warpmail.net","threadId":"32602","inReplyTo":"7vip6z54rh.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-15T09:44:24Z","receivedAt":"2013-01-15T09:44:24Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 15.01.2013 07:39:\n> Junio C Hamano writes:\n> \n>> Jardel Weyrich writes:\n>>\n>>> If you allow me, I'd like you to forget about the concepts for a minute, and focus on the user experience.\n>>> Imagine a simple hypothetical scenario in which the user wants to push to 2 distinct repositories. He already has cloned the repo from the 1st repository, thus (theoretically) all he needs to do, is to add a new repository for push. He then uses `remote set-url --add --push <2nd-repo>` (which I personally thought would suffice). However, if he tries to push a new commit to this remote, it would be pushed _only_ to the 2nd-repo.\n>>\n>> The primary reason behind push-url was that\n>>\n>> (1) usually you push to and fetch from the same, so no pushUrl is\n>> ever needed, just a single Url will do (this is often true for\n>> cvs/svn style shared repository workflow); and\n>>\n>> (2) sometimes you want to fetch from one place and push to another\n>> (this is often true for \"fetch from upstream, push to my own\n>> and ask upstream to pull from it\" workflow), and in that case\n>> you want pushUrl in addition to Url. Most importantly, in this\n>> case, you do *NOT* want to push to Url. You only push to\n>> pushUrl.\n>>\n>> Setting *one* pushURL is a way to say \"That URL I fetch from is\n>> *not* the place I want to push (I may not even be able to push\n>> there); when I say 'push', push there instead\". Your proposed\n>> semantics will make it impossible to arrange such an asymmetric\n>> setting.\n> \n> Now I think I finally see where that misunderstanding comes from.\n> It is \"remote -v\" that is misdesigned.\n> \n> $ git clone ../there here\n> $ cd here\n> $ git remote -v\n> origin /var/tmp/there (fetch)\n> origin /var/tmp/there (push)\n> \n> This is totally bogus. It should report something like this:\n> \n> $ git remote -v\n> origin /var/tmp/there (fetch/push)\n> \n> Then after running \"git remote set-url --push origin ../another\" we\n> should see\n> \n> $ git remote -v\n> origin /var/tmp/there (fetch)\n> origin /var/tmp/another (push)\n> \n> which would make it clear that the original fetch/push came from the\n> (1) usuall you push and fetch from the same place so there is only\n> one setting, and the two lines came from the (2) sometimes you need\n> a separate places to fetch from and push to.\n\nYes, that is one big source of misunderstanding. Cleaning up remote -v\nwould help, along with the man page.\n\nAlso there is a conceptual confusion: pushurl is meant to push to the\nsame repo using a different url, e.g. something authenticated\n(https/ssh) for push and something faster/easier for fetch.\n\nIt never was meant to push to several repos. That is what \"remotes\" are\nfor, and it would help if we could push to a remote group (which is\ndifficult because of refspecs etc.) easily.\n\nThat being said, I don't mind changing the behaviour of set-url.\n\n> At this point, if you say \"set-url --push origin ../third\", then\n> \"another\" will disappear and gets replaced by \"third\"; if you\n> instead say \"set-url --add --push origin ../third\", then we will see\n> two (push) lines, in addition to one (fetch), making it clear that\n> you are still in (2) above, fetching from and pushing to different\n> places, and having two places to push to.\n> \n> I misread your response\n> \n> From: Jardel Weyrich \n> Subject: Re: [BUG] Possible bug in `remote set-url --add --push`\n> Date: Sat, 12 Jan 2013 06:09:35 -0200\n> Message-ID: \n> \n> where you showed that there was only remote.origin.url (and no\n> pushurl) in the first step, and somehow thought you had a\n> remote.origin.pushurl in the first place.\n> \n"},{"id":"206940","messageId":"7v4nii5tp2.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"50F524F8.5090803@drmicha.warpmail.net","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-15T15:53:13Z","receivedAt":"2013-01-15T15:53:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Also there is a conceptual confusion: pushurl is meant to push to the\n> same repo using a different url, e.g. something authenticated\n> (https/ssh) for push and something faster/easier for fetch.\n\nThat is not necessarily true, depending on the definition of your\n\"same\". Having multiple URLs/PushURLs that refer to physically\ndifferent locations, as long as \"git push there\" immediately\nfollowed by \"git fetch here\" should work with the repositories that\nare conceptually equivalent, is a supported mode of operation. In\nfact, they being physically different _was_ the original motivation\nof the feature. See 755225d (git builtin \"push\", 2006-04-29).\n\nThe definition of the \"immediate\" above also depends on your use; it\ncould be tens of minutes (you may be fetching from git.k.org that\ncan be reached from the general public, which may be a cname for\nmultiple machines mirroring a single master.k.org that k.org account\nholders push to, and there may be propagation delays). In such a\nscenario, your URL may point at the public git.k.org, pushURL may\npoint at master.k.org, and you may have other pushURLs that point at\nother places you use as back-up locations (e.g. git.or.cz or\ngithub.com).\n\nAs long as you _mean_ to maintain their contents the same, you can\ncall them conceptually \"the same repo\" and your statement becomes\ntrue.\n\n> It never was meant to push to several repos.\n\nThis is false. It _was_ designed to be used that way from day one.\n(I am not saying using it in other ways is an abuse---I am merely\nsaying that pushing to multiple physically different repositories is\nwithin its scope).\n\n> That being said, I don't mind changing the behaviour of set-url.\n\nI do not think we want to change the behaviour of set-url. What\nneeds to be fixed is the output from \"remote -v\". It should:\n\n * When there is no pushURL but there is a URL, then show it as\n (fetch/push), and you are done;\n\n * When there is one or more pushURLs and a URL, then show the URL\n as (fetch), and show pushURLs as (push), and you are done;\n\n * When there are more than one URLs, and there is no pushURL, then\n show the first URL as (fetch/push), and the remainder in a\n notation that says it is used only for push, but it shouldn't be\n the same \"(push)\"; the user has to be able to distinguish it from\n the pushURLs in a repository that also has URLs.\n\n * When there are more than one URLs, and there are one or more\n pushURLs, then show the first URL as (fetch), the other URLs\n as (unused), and the pushURLs as (push).\n\nStrictly speaking, the last one could be a misconfiguration. If you\nhave:\n\n\t[remote \"origin\"]\n \turl = one\n url = two\n pushurl = three\n pushurl = four\n\nthen your \"git fetch\" will go to one, and \"git push\" will go to\nthree and four, and two is never used.\n\nIt should also be stressed that the third one a supported\nconfiguration. With\n\n\t[remote \"origin\"]\n \turl = one\n url = two\n\nyour \"git fetch\" goes to one, and your \"git push\" will go to one and\ntwo. This is the originally intended use case of 755225d. It is to\npush to and fetch from master.k.org (think of \"one\" above) and in\naddition to push to backup.github.com (\"two\").\n"},{"id":"207039","messageId":"50F668FB.5000805@drmicha.warpmail.net","threadId":"32602","inReplyTo":"7v4nii5tp2.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-16T08:46:51Z","receivedAt":"2013-01-16T08:46:51Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:\n> Michael J Gruber writes:\n> \n>> Also there is a conceptual confusion: pushurl is meant to push to the\n>> same repo using a different url, e.g. something authenticated\n>> (https/ssh) for push and something faster/easier for fetch.\n> \n> That is not necessarily true, depending on the definition of your\n> \"same\". Having multiple URLs/PushURLs that refer to physically\n> different locations, as long as \"git push there\" immediately\n> followed by \"git fetch here\" should work with the repositories that\n> are conceptually equivalent, is a supported mode of operation. In\n\nThat is my definition of \"same\", in the sense of \"object-and-ref-same\"\nwhen \"in-sync\" (at least regarding all pushed refs; there may be more\nthere).\n\n> fact, they being physically different _was_ the original motivation\n> of the feature. See 755225d (git builtin \"push\", 2006-04-29).\n\nI thought it was about unauthenticated git-protocol vs. git+ssh but was\nwrong.\n\n> The definition of the \"immediate\" above also depends on your use; it\n> could be tens of minutes (you may be fetching from git.k.org that\n> can be reached from the general public, which may be a cname for\n> multiple machines mirroring a single master.k.org that k.org account\n> holders push to, and there may be propagation delays). In such a\n> scenario, your URL may point at the public git.k.org, pushURL may\n> point at master.k.org, and you may have other pushURLs that point at\n> other places you use as back-up locations (e.g. git.or.cz or\n> github.com).\n\nYes. That is also why we fetch from one fetch URL only, because we\nassume they point at the \"same\" repo and don't need to check.\n\n> As long as you _mean_ to maintain their contents the same, you can\n> call them conceptually \"the same repo\" and your statement becomes\n> true.\n> \n>> It never was meant to push to several repos.\n> \n> This is false. It _was_ designed to be used that way from day one.\n\nIt is very true with me definition of \"same\" ;)\n\n> (I am not saying using it in other ways is an abuse---I am merely\n> saying that pushing to multiple physically different repositories is\n> within its scope).\n> \n>> That being said, I don't mind changing the behaviour of set-url.\n> \n> I do not think we want to change the behaviour of set-url. What\n> needs to be fixed is the output from \"remote -v\". It should:\n> \n> * When there is no pushURL but there is a URL, then show it as\n> (fetch/push), and you are done;\n> \n> * When there is one or more pushURLs and a URL, then show the URL\n> as (fetch), and show pushURLs as (push), and you are done;\n> \n> * When there are more than one URLs, and there is no pushURL, then\n> show the first URL as (fetch/push), and the remainder in a\n> notation that says it is used only for push, but it shouldn't be\n> the same \"(push)\"; the user has to be able to distinguish it from\n> the pushURLs in a repository that also has URLs.\n\nMaybe \"(fetch fallback/push)\" if we do use it as a fallback? If we don't\nwe probably should?\n\n> * When there are more than one URLs, and there are one or more\n> pushURLs, then show the first URL as (fetch), the other URLs\n> as (unused), and the pushURLs as (push).\n> \n> Strictly speaking, the last one could be a misconfiguration. If you\n> have:\n> \n> \t[remote \"origin\"]\n> \turl = one\n> url = two\n> pushurl = three\n> pushurl = four\n> \n> then your \"git fetch\" will go to one, and \"git push\" will go to\n> three and four, and two is never used.\n\nDo we fall back to two if one is unavailable? In any case, people may\nuse a configuration like that to keep track of mirrors and shuffle\naround the fetch lines (rather than commenting/uncommenting) when one\ngoes offline.\n\n> It should also be stressed that the third one a supported\n> configuration. With\n> \n> \t[remote \"origin\"]\n> \turl = one\n> url = two\n> \n> your \"git fetch\" goes to one, and your \"git push\" will go to one and\n> two. This is the originally intended use case of 755225d. It is to\n> push to and fetch from master.k.org (think of \"one\" above) and in\n> addition to push to backup.github.com (\"two\").\n\nMichael\n"},{"id":"207041","messageId":"a5bf3511b3ecf4e9243d550d11ab977f95ecea30.1358331096.git.git@drmicha.warpmail.net","threadId":"32602","inReplyTo":"7v4nii5tp2.fsf@alter.siamese.dyndns.org","subject":"[PATCH] git-remote: distinguish between default and configured URLs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-16T10:14:48Z","receivedAt":"2013-01-16T10:14:48Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"The current output of \"git remote -v\" does not distinguish between\nexplicitly configured push URLs and those coming from fetch lines.\n\nRevise the output so so that URLs are distinguished by their labels:\n\n(fetch): fetch config used for fetching only\n(fetch/push): fetch config used for fetching and pushing\n(fetch fallback/push): fetch config used for pushing only\n(fetch fallback): fetch config which is unused\n(push): push config used for pushing\n\nSigned-off-by: Michael J Gruber \n---\nMaybe something like this? It even seems to make the code in get_one_entry\nclearer.\n\nI yet have to look at the tests, doc and other git-remote invocations.\n\n builtin/remote.c | 31 +++++++++++++++++--------------\n 1 file changed, 17 insertions(+), 14 deletions(-)\n\ndiff --git a/builtin/remote.c b/builtin/remote.c\nindex 937484d..ec07109 100644\n--- a/builtin/remote.c\n+++ b/builtin/remote.c\n@@ -1509,25 +1509,28 @@ static int get_one_entry(struct remote *remote, void *priv)\n {\n \tstruct string_list *list = priv;\n \tstruct strbuf url_buf = STRBUF_INIT;\n-\tconst char **url;\n-\tint i, url_nr;\n+\tchar *fetchurl0, *fetchurl1;\n+\tint i;\n+\n+\tif (remote->pushurl_nr > 0) {\n+\t\tfetchurl0 = \"fetch\";\n+\t\tfetchurl1 = \"fetch fallback\";\n+\t} else {\n+\t\tfetchurl0 = \"fetch/push\";\n+\t\tfetchurl1 = \"fetch fallback/push\";\n+\t}\n \n-\tif (remote->url_nr > 0) {\n-\t\tstrbuf_addf(&url_buf, \"%s (fetch)\", remote->url[0]);\n+\tfor (i = 0; i < remote->url_nr; i++) {\n+\t\tstrbuf_addf(&url_buf, \"%s (%s)\", remote->url[0], i ? fetchurl1 : fetchurl0);\n \t\tstring_list_append(list, remote->name)->util =\n \t\t\t\tstrbuf_detach(&url_buf, NULL);\n-\t} else\n+\t} /* else */\n+\tif (remote->url_nr == 0)\n \t\tstring_list_append(list, remote->name)->util = NULL;\n-\tif (remote->pushurl_nr) {\n-\t\turl = remote->pushurl;\n-\t\turl_nr = remote->pushurl_nr;\n-\t} else {\n-\t\turl = remote->url;\n-\t\turl_nr = remote->url_nr;\n-\t}\n-\tfor (i = 0; i < url_nr; i++)\n+\n+\tfor (i = 0; i < remote->pushurl_nr; i++)\n \t{\n-\t\tstrbuf_addf(&url_buf, \"%s (push)\", url[i]);\n+\t\tstrbuf_addf(&url_buf, \"%s (push)\", remote->pushurl[i]);\n \t\tstring_list_append(list, remote->name)->util =\n \t\t\t\tstrbuf_detach(&url_buf, NULL);\n \t}\n-- \n1.8.1.1.456.g93e7b0a\n"},{"id":"207043","messageId":"50F6807A.6080800@drmicha.warpmail.net","threadId":"32602","inReplyTo":"a5bf3511b3ecf4e9243d550d11ab977f95ecea30.1358331096.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] git-remote: distinguish between default and configured URLs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-16T10:27:06Z","receivedAt":"2013-01-16T10:27:06Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 16.01.2013 11:14:\n> The current output of \"git remote -v\" does not distinguish between\n> explicitly configured push URLs and those coming from fetch lines.\n> \n> Revise the output so so that URLs are distinguished by their labels:\n> \n> (fetch): fetch config used for fetching only\n> (fetch/push): fetch config used for fetching and pushing\n> (fetch fallback/push): fetch config used for pushing only\n> (fetch fallback): fetch config which is unused\n> (push): push config used for pushing\n> \n> Signed-off-by: Michael J Gruber \n> ---\n> Maybe something like this? It even seems to make the code in get_one_entry\n> clearer.\n> \n> I yet have to look at the tests, doc and other git-remote invocations.\n\nOkay, so \"git remote show remotename\" copied the logic from \"git remote\n-v\" but neither reused the code nor the output format. I guess we'd have\nto implement the new logic and keep the old format? Refactoring would\nrequire settling on a common format. Both outputs should be\nui-as-ui-can, but I'm afraid people are still grepping the output in\ntheir scripts :(\n\nMichael\n"},{"id":"207045","messageId":"20130116104222.GA15125@farnsworth.metanate.com","threadId":"32602","inReplyTo":"a5bf3511b3ecf4e9243d550d11ab977f95ecea30.1358331096.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] git-remote: distinguish between default and configured URLs","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-16T10:42:22Z","receivedAt":"2013-01-16T10:42:22Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:\n> The current output of \"git remote -v\" does not distinguish between\n> explicitly configured push URLs and those coming from fetch lines.\n> \n> Revise the output so so that URLs are distinguished by their labels:\n> \n> (fetch): fetch config used for fetching only\n> (fetch/push): fetch config used for fetching and pushing\n> (fetch fallback/push): fetch config used for pushing only\n> (fetch fallback): fetch config which is unused\n> (push): push config used for pushing\n\nHow does this interact with url..pushInsteadOf?\n\nI have a global rule to convert git:// URLs to ssh:// for pushing:\n\n [url \"git@example.com:\"]\n pushInsteadOf = git://example.com/\n\nWith only a URL configured for a remote (no pushURL), I get (with Git\n1.8.1):\n\n origin git://example.com/repository.git (fetch)\n origin git@example.com:repository.git (push)\n\n>From the original discussion in this thread, I think that if I did\n\"git remote set-url --add --push \" it would replace my current push\nURL, and the change to \"(fetch/push)\" doesn't help in this case.\n\nShould there be special handling for pushInsteadOf here?\n\n\nJohn\n"},{"id":"207048","messageId":"50F6A0F0.70800@drmicha.warpmail.net","threadId":"32602","inReplyTo":"20130116104222.GA15125@farnsworth.metanate.com","subject":"Re: [PATCH] git-remote: distinguish between default and configured URLs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-16T12:45:36Z","receivedAt":"2013-01-16T12:45:36Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"John Keeping venit, vidit, dixit 16.01.2013 11:42:\n> On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:\n>> The current output of \"git remote -v\" does not distinguish between\n>> explicitly configured push URLs and those coming from fetch lines.\n>>\n>> Revise the output so so that URLs are distinguished by their labels:\n>>\n>> (fetch): fetch config used for fetching only\n>> (fetch/push): fetch config used for fetching and pushing\n>> (fetch fallback/push): fetch config used for pushing only\n>> (fetch fallback): fetch config which is unused\n>> (push): push config used for pushing\n> \n> How does this interact with url..pushInsteadOf?\n> \n> I have a global rule to convert git:// URLs to ssh:// for pushing:\n> \n> [url \"git@example.com:\"]\n> pushInsteadOf = git://example.com/\n> \n> With only a URL configured for a remote (no pushURL), I get (with Git\n> 1.8.1):\n> \n> origin git://example.com/repository.git (fetch)\n> origin git@example.com:repository.git (push)\n> \n> From the original discussion in this thread, I think that if I did\n> \"git remote set-url --add --push \" it would replace my current push\n> URL, and the change to \"(fetch/push)\" doesn't help in this case.\n> \n> Should there be special handling for pushInsteadOf here?\n> \n> \n> John\n\nThanks for pointing out this case.\n\nThe new code would still list this as two separate URLs because they\nreally are; whether they come from two config entries or from one being\nsubject to two different insteadof expansions is completely opaque to\nbuiltin/remote.c, unless remote.c learns to stick that additional info\ninto struct remote somehow.\n\nIn short, the separate listing is correct, but in this case there's no\nimprovement in readability.\n\nWe could still say that (push)InsteadOf is a power feature and we want\nto help the \"normal\" case, but it's a bit half-assed. In the end we\nmight even have to keep track of insteadof-expansions and display those\nalso (i.e. \"expanded from...\")?\n\nMichael\n"},{"id":"207049","messageId":"20130116130425.GB15125@farnsworth.metanate.com","threadId":"32602","inReplyTo":"50F6A0F0.70800@drmicha.warpmail.net","subject":"Re: [PATCH] git-remote: distinguish between default and configured URLs","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-01-16T13:04:25Z","receivedAt":"2013-01-16T13:04:25Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jan 16, 2013 at 01:45:36PM +0100, Michael J Gruber wrote:\n> John Keeping venit, vidit, dixit 16.01.2013 11:42:\n>> On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:\n>>> The current output of \"git remote -v\" does not distinguish between\n>>> explicitly configured push URLs and those coming from fetch lines.\n>>>\n>>> Revise the output so so that URLs are distinguished by their labels:\n>>>\n>>> (fetch): fetch config used for fetching only\n>>> (fetch/push): fetch config used for fetching and pushing\n>>> (fetch fallback/push): fetch config used for pushing only\n>>> (fetch fallback): fetch config which is unused\n>>> (push): push config used for pushing\n>> \n>> How does this interact with url..pushInsteadOf?\n>> \n>> I have a global rule to convert git:// URLs to ssh:// for pushing:\n>> \n>> [url \"git@example.com:\"]\n>> pushInsteadOf = git://example.com/\n>> \n>> With only a URL configured for a remote (no pushURL), I get (with Git\n>> 1.8.1):\n>> \n>> origin git://example.com/repository.git (fetch)\n>> origin git@example.com:repository.git (push)\n>> \n>> From the original discussion in this thread, I think that if I did\n>> \"git remote set-url --add --push \" it would replace my current push\n>> URL, and the change to \"(fetch/push)\" doesn't help in this case.\n>> \n>> Should there be special handling for pushInsteadOf here?\n> \n> Thanks for pointing out this case.\n> \n> The new code would still list this as two separate URLs because they\n> really are; whether they come from two config entries or from one being\n> subject to two different insteadof expansions is completely opaque to\n> builtin/remote.c, unless remote.c learns to stick that additional info\n> into struct remote somehow.\n\nOK. I like the new format, I was just wondering if it was a simple\nenhancement to indicate a pushInsteadOf URL specially as well.\n\n> In short, the separate listing is correct, but in this case there's no\n> improvement in readability.\n> \n> We could still say that (push)InsteadOf is a power feature and we want\n> to help the \"normal\" case, but it's a bit half-assed. In the end we\n> might even have to keep track of insteadof-expansions and display those\n> also (i.e. \"expanded from...\")?\n\nGiven that it's not a trivial enhancement, I'd accept the argument that\nsomeone who has configured pushInsteadOf can be expected to understand\nthe underlying git-config semantics of \"git remote set-url\".\n\n\nJohn\n"},{"id":"207059","messageId":"7v622xyvnd.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"50F668FB.5000805@drmicha.warpmail.net","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-16T15:50:30Z","receivedAt":"2013-01-16T15:50:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:\n> ...\n>> * When there are more than one URLs, and there is no pushURL, then\n>> show the first URL as (fetch/push), and the remainder in a\n>> notation that says it is used only for push, but it shouldn't be\n>> the same \"(push)\"; the user has to be able to distinguish it from\n>> the pushURLs in a repository that also has URLs.\n>\n> Maybe \"(fetch fallback/push)\" if we do use it as a fallback? If we don't\n> we probably should?\n\nI actually think my earlier \"it shouldn't be the same (push)\" is not\nneeded and probably is actively wrong. Just like you can tell\nbetween\n\n (only one .url) (both .url and .pushurl)\n\n origin there (fetch/push) origin there (fetch)\n origin there (push)\n\neven when the value of the URL/PushURL, i.e. \"there\", is the same\nbetween .url and .pushurl, you should be able to tell between\n\n (two .url, no .pushurl) (one .url and one .pushurl)\n\n origin there (fetch/push) origin there (fetch)\n origin another (push) origin another (push)\n\nSo let's not make it too complex and forget about the different kind\nof \"(push)\".\n\nA case that is a potential misconfiguration would look like:\n\n (two .url, one .pushurl)\n\n origin there (fetch)\n origin some (unused)\n origin another (push)\n\nI think.\n"},{"id":"207060","messageId":"CABURp0rR_wB6vcjrZajQU_=AVVvBq-aTGpggh5XxdCMYis3-ag@mail.gmail.com","threadId":"32602","inReplyTo":"7v4nii5tp2.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-01-16T16:15:37Z","receivedAt":"2013-01-16T16:15:37Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano wrote:\n> Michael J Gruber writes:\n>\n>> That being said, I don't mind changing the behaviour of set-url.\n>\n> I do not think we want to change the behaviour of set-url.\n\nI agree with Michael that changing the set-url behavior would be\nappropriate here. If I say \"--add\" this pushUrl, don't I mean to\ncreate an additional url which is pushed to?\n\nI agree that it makes the config situation messy; this is currently a\n\"clean\" sequence, in that it leaves the config unchanged after both\nsteps are completed:\n\n git remote set-url --add --push origin /tmp/foo\n git remote set-url --delete --push origin /tmp/foo\n\nIf the behavior is changed like Michael suggested, it would not leave\nthe config clean (unless heroic steps were taken to keep track). But\nI'm not sure that's such a bad thing. In simple command sequences,\nthe results would be clean and the only behavior change is that the\ninitial \"--add\" really acts like \"add\" and not \"replace\". But more\ncomplex sequences could be devised which were affected by this change.\n\nI'm curious, Junio. Do you think the set-url behavior is correct\nas-is, or that changing it will cause breakage for some workflows, or\nthat it complicates the operation too much for people who are already\nused to the config layout?\n\nPhil\n"},{"id":"207061","messageId":"50F6D30B.9030703@drmicha.warpmail.net","threadId":"32602","inReplyTo":"7v622xyvnd.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-16T16:19:23Z","receivedAt":"2013-01-16T16:19:23Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 16.01.2013 16:50:\n> Michael J Gruber writes:\n> \n>> Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:\n>> ...\n>>> * When there are more than one URLs, and there is no pushURL, then\n>>> show the first URL as (fetch/push), and the remainder in a\n>>> notation that says it is used only for push, but it shouldn't be\n>>> the same \"(push)\"; the user has to be able to distinguish it from\n>>> the pushURLs in a repository that also has URLs.\n>>\n>> Maybe \"(fetch fallback/push)\" if we do use it as a fallback? If we don't\n>> we probably should?\n> \n> I actually think my earlier \"it shouldn't be the same (push)\" is not\n> needed and probably is actively wrong. Just like you can tell\n> between\n> \n> (only one .url) (both .url and .pushurl)\n> \n> origin there (fetch/push) origin there (fetch)\n> origin there (push)\n> \n> even when the value of the URL/PushURL, i.e. \"there\", is the same\n> between .url and .pushurl, you should be able to tell between\n> \n> (two .url, no .pushurl) (one .url and one .pushurl)\n> \n> origin there (fetch/push) origin there (fetch)\n> origin another (push) origin another (push)\n> \n> So let's not make it too complex and forget about the different kind\n> of \"(push)\".\n> \n> A case that is a potential misconfiguration would look like:\n> \n> (two .url, one .pushurl)\n> \n> origin there (fetch)\n> origin some (unused)\n> origin another (push)\n> \n> I think.\n\nI'm sorry but E_NOPARSE. I can't grok the above at all. But I'll try\nagain tomorrow ;)\n\nIn any case, the issue with (push)instead of that John mentions bothers\nme: there are \"two specified URLs\" but one URL in config only; my patch\ndoesn't make that case clearer at all. My early attempts at amending\nstruct remote produced too many segfaults to continue today...\n\nMichael\n"},{"id":"207062","messageId":"50F6D43D.2000509@drmicha.warpmail.net","threadId":"32602","inReplyTo":"CABURp0rR_wB6vcjrZajQU_=AVVvBq-aTGpggh5XxdCMYis3-ag@mail.gmail.com","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-01-16T16:24:29Z","receivedAt":"2013-01-16T16:24:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Phil Hord venit, vidit, dixit 16.01.2013 17:15:\n> On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano wrote:\n>> Michael J Gruber writes:\n>>\n>>> That being said, I don't mind changing the behaviour of set-url.\n>>\n>> I do not think we want to change the behaviour of set-url.\n> \n> I agree with Michael that changing the set-url behavior would be\n> appropriate here. If I say \"--add\" this pushUrl, don't I mean to\n> create an additional url which is pushed to?\n\nI said I wouldn't mind, I didn't vote for it.\n\n> I agree that it makes the config situation messy; this is currently a\n> \"clean\" sequence, in that it leaves the config unchanged after both\n> steps are completed:\n> \n> git remote set-url --add --push origin /tmp/foo\n> git remote set-url --delete --push origin /tmp/foo\n> \n> If the behavior is changed like Michael suggested, it would not leave\n> the config clean (unless heroic steps were taken to keep track). But\n> I'm not sure that's such a bad thing. In simple command sequences,\n> the results would be clean and the only behavior change is that the\n> initial \"--add\" really acts like \"add\" and not \"replace\". But more\n> complex sequences could be devised which were affected by this change.\n> \n> I'm curious, Junio. Do you think the set-url behavior is correct\n> as-is, or that changing it will cause breakage for some workflows, or\n> that it complicates the operation too much for people who are already\n> used to the config layout?\n\nFor \"set url --add --push\" on top of a push url only being defaulted\nfrom a fetch url, both behaviours (replace or add, i.e. current or new)\nmake sense to me. So the questions are:\n\n- Is it worth and possible changing?\n- How to best describe it in \"remote -v\" and \"remote show\" output?\n\nMy patch answered to \"no\" to the first question and answers the second\none in cases where (push)insteadof is not used to transform one fetch\nconfig into two different urls for fetch and push. I think :)\n\nMichael\n"},{"id":"207097","messageId":"7vvcaxvstp.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"50F6A0F0.70800@drmicha.warpmail.net","subject":"Re: [PATCH] git-remote: distinguish between default and configured URLs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-16T19:19:46Z","receivedAt":"2013-01-16T19:19:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> In short, the separate listing is correct, but in this case there's no\n> improvement in readability.\n\nYes, I think the \"insteadOf\" rewrite is a related but a separate\nissue.\n\nIs \"remote -v\" meant for diagnosing remote.origin.{url,pushurl} that\nare misconfigured?\n\nIf not, the output just should just say the final outcome, i.e. what\ndestinations we will fetch from and push to, without cluttering the\noutput.\n\nIf on the other hand it is to help users debug their configuration,\nthe output also needs to explain exactly what made us decide those\ndestinations to use (e.g. to discover there was a leftover insteadof\nin $HOME/.gitconfig the user forgot about).\n"},{"id":"207098","messageId":"m2ip6x0vtk.fsf@igel.home","threadId":"32602","inReplyTo":"7v622xyvnd.fsf@alter.siamese.dyndns.org","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-01-16T19:30:47Z","receivedAt":"2013-01-16T19:30:47Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano writes:\n\n> I actually think my earlier \"it shouldn't be the same (push)\" is not\n> needed and probably is actively wrong. Just like you can tell\n> between\n>\n> (only one .url) (both .url and .pushurl)\n>\n> origin there (fetch/push) origin there (fetch)\n> origin there (push)\n\nWhat should happen when you have a .pushinsteadof configured that\nmodifies .url for pushing?\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"207100","messageId":"7vr4lkx5gq.fsf@alter.siamese.dyndns.org","threadId":"32602","inReplyTo":"m2ip6x0vtk.fsf@igel.home","subject":"Re: [BUG] Possible bug in `remote set-url --add --push`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-01-16T20:01:25Z","receivedAt":"2013-01-16T20:01:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> Junio C Hamano writes:\n>\n>> I actually think my earlier \"it shouldn't be the same (push)\" is not\n>> needed and probably is actively wrong. Just like you can tell\n>> between\n>>\n>> (only one .url) (both .url and .pushurl)\n>>\n>> origin there (fetch/push) origin there (fetch)\n>> origin there (push)\n>\n> What should happen when you have a .pushinsteadof configured that\n> modifies .url for pushing?\n\nI think push should work like this:\n\n * the user gives us a nickname;\n\n * we look at remote.$nickname.pushurl (and if there isn't,\n remote.$nickname.url) to decide the logical URLs to push to;\n\n * for each logical URL we decided to push, we look at\n url.*.pushInsteadOf to see if there is one that match the $URL\n (and if there isn't url.*.insteadOf), and map the logical URL to\n the final destination.\n\nSo that we can instruct \"push\" to push, when pushing into a\nrepository that logically resides at git://git.k.org/pub/,\nto instead push into the repository via git-over-ssh, e.g.\n\n [remote \"korg\"]\n\turl = git://git.k.org/pub/scm/git/git.git/\n\n [url \"git.k.org:/pub/\"]\n pushInsteadOf = git://git.k.org/pub/\n\nwithout affecting the fetching side.\n\nAs I said in a separate message, the above \"fetch/push\" vs \"fetch\"\nand \"push\" distinction is not descriptive enough to express the post\nrewriting that is done with insteadOf; it only helps debugging\nmisconfiguration between .url vs .pushurl, which may be better than\nthe status quo but is not ideal.\n"}]}