On Thu, Jan 05, 2017 at 05:53:30AM -0800, Stefan Beller wrote: > > My scenario is as follows: I use 2 SSH keys for GitHub, for private and > > work-related repositories. My default key is my private key. So when I > > clone a work repository and try getting the submodules, `git submodule > > update --init` fails. This is also the case when setting > > `core.sshCommand` and `url.*.insteadOf` (useful for substituting > > "github.com" by some ~/.ssh/config'ured host). > > which is why e.g. > git config --global url.https://github.com/.insteadOf git://github.com/ > is not your preferred way here. > > There was some discussion a couple of weeks ago, which settings > should be kept when recursing into submodules, Jacob and Jeff cc'd. The only discussion I recall was from last May. But that was about "-c" config on the command-line, and the end decision was that we pass it all down to submodules, per 89044baa8b (submodule: stop sanitizing config options, 2016-05-04). I think the problem here is more about propagating options from the superproject's repo-level config into the submodules. AFAIK we do not do that at all, but I may have missed some patches in that area. Another approach would be conditional config includes based on the repo path. With the patches discussed in [1], you could do something like: git config --global include./path/to/work/repos.path .gitconfig-work git config -f ~/.gitconfig-work url.foo.insteadOf bar -Peff [1] http://public-inbox.org/git/20160626070617.30211-1-pclouds@xxxxxxxxx/