{"thread":{"id":"36905","subject":"Why doesn't git-fetch obey -c \"remote.origin.url\" on the command-line?","startedAt":"2014-06-13T07:37:07Z","lastAt":"2014-06-16T12:48:02Z","messageCount":3,"participants":["Ævar Arnfjörð Bjarmason","Jeff King","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"244065","messageId":"CACBZZX4MyaOKkCvTSKhZtyRMFvpBMiMGz2ix3OxMz_s=P-=p=w@mail.gmail.com","threadId":"36905","inReplyTo":null,"subject":"Why doesn't git-fetch obey -c \"remote.origin.url\" on the command-line?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2014-06-13T07:37:07Z","receivedAt":"2014-06-13T07:37:07Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On a git built from the master branch just now:\n\n $ ./git config remote.origin.url\nhttps://code.google.com/p/git-core/\n$ ./git -c remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git\nconfig remote.origin.url\ngit://git.sourceforge.jp/gitroot/git-core/git.git\n$ GIT_TRACE=1 ./git -c\nremote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git\nfetch 2>&1 | head -n 2\ntrace: built-in: git 'fetch'\ntrace: run_command: 'git-remote-https' 'origin'\n'https://code.google.com/p/git-core/'\n\nI'd expect this to try to fetch from the remote.origin.url I specified\non the command-line, but for some reason fetch doesn't pick that up.\nIsn't this a bug?\n\nThe use case for this is to have a script in cron that does a pull of\nrepositories via http while the developers expecting to occasionally\nuse those repositories as work directories should transparently be\nable to pull/push from them.\n\nI know about remote.origin.pushurl, but I'd prefer pulls to also be\nover ssh in those cases, because then you don't have to worry about\nproxy settings (different for the devs & that automated script).\n\nI could fix this, but I thought I'd first send a question about\nwhether this shouldn't be considered a bug, and I haven't dug into\nthis yet but I think that configuration passed via the -c option\nshould *always* override any other config Git may get from elsewhere.\n"},{"id":"244067","messageId":"20140613075110.GH7908@sigill.intra.peff.net","threadId":"36905","inReplyTo":"CACBZZX4MyaOKkCvTSKhZtyRMFvpBMiMGz2ix3OxMz_s=P-=p=w@mail.gmail.com","subject":"Re: Why doesn't git-fetch obey -c \"remote.origin.url\" on the command-line?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-06-13T07:51:11Z","receivedAt":"2014-06-13T07:51:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2014 at 09:37:07AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> On a git built from the master branch just now:\n> \n>  $ ./git config remote.origin.url\n> https://code.google.com/p/git-core/\n> $ ./git -c remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git\n> config remote.origin.url\n> git://git.sourceforge.jp/gitroot/git-core/git.git\n> $ GIT_TRACE=1 ./git -c\n> remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git\n> fetch 2>&1 | head -n 2\n> trace: built-in: git 'fetch'\n> trace: run_command: 'git-remote-https' 'origin'\n> 'https://code.google.com/p/git-core/'\n> \n> I'd expect this to try to fetch from the remote.origin.url I specified\n> on the command-line, but for some reason fetch doesn't pick that up.\n> Isn't this a bug?\n\nI think this is an alternate version of the report in [1].\n\nThe short answer is: remote.*.url is a multi-valued config option, and\nyou can only append to (not override) such options with \"git -c\". Try\nusing insteadOf.\n\n-Peff\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/250427\n"},{"id":"244246","messageId":"24CCEC485B8B4C65B7785462369CBFF0@PhilipOakley","threadId":"36905","inReplyTo":"20140613075110.GH7908@sigill.intra.peff.net","subject":"Re: Why doesn't git-fetch obey -c \"remote.origin.url\" on the command-line?","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-06-16T12:48:02Z","receivedAt":"2014-06-16T12:48:02Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" <peff@peff.net>\n> On Fri, Jun 13, 2014 at 09:37:07AM +0200, Ævar Arnfjörð Bjarmason\n> wrote:\n>\n>> On a git built from the master branch just now:\n>>\n>>  $ ./git config remote.origin.url\n>> https://code.google.com/p/git-core/\n>> $ ./git -c\n>> remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git\n>> config remote.origin.url\n>> git://git.sourceforge.jp/gitroot/git-core/git.git\n>> $ GIT_TRACE=1 ./git -c\n>> remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git\n>> fetch 2>&1 | head -n 2\n>> trace: built-in: git 'fetch'\n>> trace: run_command: 'git-remote-https' 'origin'\n>> 'https://code.google.com/p/git-core/'\n>>\n>> I'd expect this to try to fetch from the remote.origin.url I\n>> specified\n>> on the command-line, but for some reason fetch doesn't pick that up.\n>> Isn't this a bug?\n\nIf anything, given Peff's clarification below, it's a bug in the way the\ndocumentation has (not) communicated this trap for the unwary.\n\nThe question would then become \"What warning should be given and where\nshould it/they be placed?\" It should go within the documentation where \nfolk\nlook to check that the command innvocations were as expected. (It may\nalso be a 'common knowledge' issue [2]).\n\nI already see that the git(1) man page for the '-c' option doesn't cover\nthe mult-value config option case.\n\nThe config-api suggests the common priority order where later values\noverride newer values.\n\nI've done a little documentation patch to cover the current situation.\n\nI've also copied in Robert (fuz) (from [1]) and Tanay (updating the\nreading of config files).\n\n>\n> I think this is an alternate version of the report in [1].\n>\n> The short answer is: remote.*.url is a multi-valued config option, and\n> you can only append to (not override) such options with \"git -c\". Try\n> using insteadOf.\n>\n> -Peff\n>\n> [1] http://article.gmane.org/gmane.comp.version-control.git/250427\n> --\n[2] \"It ain't what you don't know that gets you into trouble. It's what\nyou know for sure that just ain't so.\" Mark Twain \n"}]}