{"thread":{"id":"51389","subject":"Multiple urls for remotes?","startedAt":"2019-06-26T23:52:52Z","lastAt":"2019-06-27T01:19:17Z","messageCount":2,"participants":["Mike Hommey","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"378105","messageId":"20190626235247.nhw45da52rz46mad@glandium.org","threadId":"51389","inReplyTo":null,"subject":"Multiple urls for remotes?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2019-06-26T23:52:47Z","receivedAt":"2019-06-26T23:52:52Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI was surprised to figure out that urls/pushurls set up for remotes can\nbe set multiple times, and that those urls end up being used\nsequentially.\n\nSadly, this has the side effect that one cannot override the config from\nthe command line, as the url is then added as an extra url, which is\ntried after the already configured one.\n\ne.g.\n    git -c remote.origin.url=/tmp/foo push origin\n\nwill keep pushing to wherever the .git/config's remote.origin.url points\nto.\n\nWith all the configuration items that work this way, it's actually kind\nof sad that it's not possible to force the value from the command line to\noverride anything that is set in the configuration.\n\nIt's worth noting that the documentation for -c says:\n\n    Pass a configuration parameter to the command. The value given will\n    override values from configuration files.\n\n... which implies -c remote.origin.url=/tmp/foo should, in fact, replace\nany other value already set.\n\nComing back to the fact that remote.origin.url and remote.origin.pushurl\ncan actually have multiple values, it's also worth noting that none of\nthe git-config, git-fetch or git-push documentation seem to say anything\nabout the fact there can be multiple values.\n\nThe git-config documentation says:\n   remote.<name>.url\n       The URL of a remote repository. See git-fetch(1) or git-push(1).\n\n   remote.<name>.pushurl\n       The push URL of a remote repository. See git-push(1).\n\nThe git-fetch and git-push documentations always talk about _the_ URL.\n\nThe only thing that seems to be talking about this is the documentation\nfor git-remote, which has --add for set-url. There doesn't seem to be any\ndocumentation about what conditions are required for the non-primary URL\nto be used.\n\nMike\n"},{"id":"378108","messageId":"20190627011909.GA9224@genre.crustytoothpaste.net","threadId":"51389","inReplyTo":"20190626235247.nhw45da52rz46mad@glandium.org","subject":"Re: Multiple urls for remotes?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-06-27T01:19:09Z","receivedAt":"2019-06-27T01:19:17Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2019-06-26 at 23:52:47, Mike Hommey wrote:\n> Hi,\n> \n> I was surprised to figure out that urls/pushurls set up for remotes can\n> be set multiple times, and that those urls end up being used\n> sequentially.\n\nYes, this is actually a feature. It's useful when you want to push to\nmultiple remotes at once. For instance, I want to push my Git changes to\nboth my server and to GitHub, and I can do so simply with \"git push def\nHEAD\".\n\n> Sadly, this has the side effect that one cannot override the config from\n> the command line, as the url is then added as an extra url, which is\n> tried after the already configured one.\n> \n> e.g.\n>     git -c remote.origin.url=/tmp/foo push origin\n> \n> will keep pushing to wherever the .git/config's remote.origin.url points\n> to.\n>\n> With all the configuration items that work this way, it's actually kind\n> of sad that it's not possible to force the value from the command line to\n> override anything that is set in the configuration.\n\nThis is true for all config options that operate on multiple items, and\nit's a known limitation. Some configuration options allow specifying an\nempty value to reset the list, but this isn't one of them.\n\nThis also tends to bite people when they have set things like refspecs\nfor origin in their ~/.gitconfig, but then decide they don't want that\nbehavior on a repo basis.\n\nThere was some discussion of this issue in a subthread of my multiple\nhooks series recently. In order to have a standard way to reset this,\nwe'd either need to have each configuration option learn how to reset\nitself or we'd need to buffer configuration options until all of the\nvalues are parsed and ignore things before the reset marker. We'd also\nneed a standard reset marker that can be used consistently. Nobody has\nyet picked this up, but of course patches are welcome.\n\n> It's worth noting that the documentation for -c says:\n> \n>     Pass a configuration parameter to the command. The value given will\n>     override values from configuration files.\n> \n> ... which implies -c remote.origin.url=/tmp/foo should, in fact, replace\n> any other value already set.\n\nI agree this is a bug. It should probably say something like, \"The\nvalues given will act as though they were parsed after the repository\nconfiguration,\" although we'd need to make it less confusing than that.\n\n> The only thing that seems to be talking about this is the documentation\n> for git-remote, which has --add for set-url. There doesn't seem to be any\n> documentation about what conditions are required for the non-primary URL\n> to be used.\n\nFor pushes, it's either always used or it's used if preceding URLs have\nnot failed, I can't remember which. Only the first URL is used for\nfetches. I agree that better documentation here would be desirable as\nwell.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"}]}