# Why doesn't git-fetch obey -c "remote.origin.url" on the command-line? 3 messages from 2014-06-13 to 2014-06-16. Participants: Ævar Arnfjörð Bjarmason, Jeff King, Philip Oakley. Thread: https://gitlist.dev/t/36905 ## Ævar Arnfjörð Bjarmason, 2014-06-13 07:37 Subject: Why doesn't git-fetch obey -c "remote.origin.url" on the command-line? Message-ID: URL: https://gitlist.dev/e/CACBZZX4MyaOKkCvTSKhZtyRMFvpBMiMGz2ix3OxMz_s%3DP-%3Dp%3Dw%40mail.gmail.com ``` On a git built from the master branch just now: $ ./git config remote.origin.url https://code.google.com/p/git-core/ $ ./git -c remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git config remote.origin.url git://git.sourceforge.jp/gitroot/git-core/git.git $ GIT_TRACE=1 ./git -c remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git fetch 2>&1 | head -n 2 trace: built-in: git 'fetch' trace: run_command: 'git-remote-https' 'origin' 'https://code.google.com/p/git-core/' I'd expect this to try to fetch from the remote.origin.url I specified on the command-line, but for some reason fetch doesn't pick that up. Isn't this a bug? The use case for this is to have a script in cron that does a pull of repositories via http while the developers expecting to occasionally use those repositories as work directories should transparently be able to pull/push from them. I know about remote.origin.pushurl, but I'd prefer pulls to also be over ssh in those cases, because then you don't have to worry about proxy settings (different for the devs & that automated script). I could fix this, but I thought I'd first send a question about whether this shouldn't be considered a bug, and I haven't dug into this yet but I think that configuration passed via the -c option should *always* override any other config Git may get from elsewhere. ``` ## Jeff King, 2014-06-13 07:51 Subject: Re: Why doesn't git-fetch obey -c "remote.origin.url" on the command-line? Message-ID: <20140613075110.GH7908@sigill.intra.peff.net> URL: https://gitlist.dev/e/20140613075110.GH7908%40sigill.intra.peff.net In-Reply-To: ``` On Fri, Jun 13, 2014 at 09:37:07AM +0200, Ævar Arnfjörð Bjarmason wrote: > On a git built from the master branch just now: > > $ ./git config remote.origin.url > https://code.google.com/p/git-core/ > $ ./git -c remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git > config remote.origin.url > git://git.sourceforge.jp/gitroot/git-core/git.git > $ GIT_TRACE=1 ./git -c > remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git > fetch 2>&1 | head -n 2 > trace: built-in: git 'fetch' > trace: run_command: 'git-remote-https' 'origin' > 'https://code.google.com/p/git-core/' > > I'd expect this to try to fetch from the remote.origin.url I specified > on the command-line, but for some reason fetch doesn't pick that up. > Isn't this a bug? I think this is an alternate version of the report in [1]. The short answer is: remote.*.url is a multi-valued config option, and you can only append to (not override) such options with "git -c". Try using insteadOf. -Peff [1] http://article.gmane.org/gmane.comp.version-control.git/250427 ``` ## Philip Oakley, 2014-06-16 12:48 Subject: Re: Why doesn't git-fetch obey -c "remote.origin.url" on the command-line? Message-ID: <24CCEC485B8B4C65B7785462369CBFF0@PhilipOakley> URL: https://gitlist.dev/e/24CCEC485B8B4C65B7785462369CBFF0%40PhilipOakley In-Reply-To: <20140613075110.GH7908@sigill.intra.peff.net> ``` From: "Jeff King" > On Fri, Jun 13, 2014 at 09:37:07AM +0200, Ævar Arnfjörð Bjarmason > wrote: > >> On a git built from the master branch just now: >> >> $ ./git config remote.origin.url >> https://code.google.com/p/git-core/ >> $ ./git -c >> remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git >> config remote.origin.url >> git://git.sourceforge.jp/gitroot/git-core/git.git >> $ GIT_TRACE=1 ./git -c >> remote.origin.url=git://git.sourceforge.jp/gitroot/git-core/git.git >> fetch 2>&1 | head -n 2 >> trace: built-in: git 'fetch' >> trace: run_command: 'git-remote-https' 'origin' >> 'https://code.google.com/p/git-core/' >> >> I'd expect this to try to fetch from the remote.origin.url I >> specified >> on the command-line, but for some reason fetch doesn't pick that up. >> Isn't this a bug? If anything, given Peff's clarification below, it's a bug in the way the documentation has (not) communicated this trap for the unwary. The question would then become "What warning should be given and where should it/they be placed?" It should go within the documentation where folk look to check that the command innvocations were as expected. (It may also be a 'common knowledge' issue [2]). I already see that the git(1) man page for the '-c' option doesn't cover the mult-value config option case. The config-api suggests the common priority order where later values override newer values. I've done a little documentation patch to cover the current situation. I've also copied in Robert (fuz) (from [1]) and Tanay (updating the reading of config files). > > I think this is an alternate version of the report in [1]. > > The short answer is: remote.*.url is a multi-valued config option, and > you can only append to (not override) such options with "git -c". Try > using insteadOf. > > -Peff > > [1] http://article.gmane.org/gmane.comp.version-control.git/250427 > -- [2] "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." Mark Twain ```