From: "Jeff King" <p...@peff.net>
On Fri, Jun 13, 2014 at 09:37:07AM +0200, Ævar Arnfjörð Bjarmason
On a git built from the master branch just now:
$ ./git config remote.origin.url
$ ./git -c
$ GIT_TRACE=1 ./git -c
fetch 2>&1 | head -n 2
trace: built-in: git 'fetch'
trace: run_command: 'git-remote-https' 'origin'
I'd expect this to try to fetch from the remote.origin.url I
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
look to check that the command innvocations were as expected. (It may
also be a 'common knowledge' issue ).
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 ) and Tanay (updating the
reading of config files).
I think this is an alternate version of the report in .
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
 "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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html