git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Why doesn't git-fetch obey -c "remote.origin.url" on the command-line?

From
Philip Oakley <philipoakley@iee.org>
Date
Jun 16, 2014, 12:48 UTC
Message-ID
<24CCEC485B8B4C65B7785462369CBFF0@PhilipOakley>
In-Reply-To
<20140613075110.GH7908@sigill.intra.peff.net>
From: "Jeff King" <peff@peff.net>
Show 22 quoted lines
> 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).

Show 11 quoted lines
>
> 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

Previous: Jeff King
Message 3 of 3 in “Why doesn't git-fetch obey -c "remote.origin.url" on the command-line?”
  1. Ævar Arnfjörð BjarmasonJun 13, 2014
  2. Jeff KingJun 13, 2014
  3. Philip OakleyJun 16, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.