* Unexpected behavior using -c to pass url.<site>.insteadof
@ 2014-05-08 22:35 Eric Brunson
0 siblings, 0 replies; only message in thread
From: Eric Brunson @ 2014-05-08 22:35 UTC (permalink / raw)
To: git
Is this the expected operation using git -c to override gitconfig settings?
This is default behavior:
$ git ls-remote git://original.site/origin
fatal: unable to connect to original.site:
This is what I expected, override with an insteadof url using -c on the
command line:
$ git -c
url.ssh://replace.site:1234/.insteadof=git://original.site/ ls-remote
git://original.site/origin
ssh: Could not resolve hostname replace.site: Name or service not known
Create a URL in ~/.gitconfig:
$ git config --global url.ssh://other.site/.insteadof
git://original.site/
$ cat ~/.gitconfig
[url "ssh://other.site/"]
insteadof = git://original.site/
Works as expected, correctly substitutes other.site for original.site:
$ git ls-remote git://original.site/origin
ssh: Could not resolve hostname other.site: Name or service not known
The same -c command as above doesn't override the ~/.gitconfig setting,
still substitutes other.site:
$ git -c
url.ssh://replace.site:1234/.insteadof=git://original.site/ ls-remote
git://original.site/origin
ssh: Could not resolve hostname other.site: Name or service not known
I've also reproduced in git 1.9.0 and 2.0.0-rc2.
Am I simply misunderstanding the documentation, it doesn't really
discuss what should happen with multivar settings?
Thanks,
e.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2014-05-08 22:35 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-08 22:35 Unexpected behavior using -c to pass url.<site>.insteadof Eric Brunson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).