On Thu, Jan 5, 2017 at 9:02 AM, Jeff King <peff@xxxxxxxx> wrote: > 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). Oh, yeah that was the difference. > > 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. AFAIK there were no such patches yet. > > 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 Or maybe we could specialize these patches to allow includes from specific other repos, i.e. superproject(s) or worktrees. > > -Peff > > [1] http://public-inbox.org/git/20160626070617.30211-1-pclouds@xxxxxxxxx/