core.sshCommand and url.*.insteadOf for submodules

Hello mailing list,

it seems like that the `core.sshCommand` and `url.*.insteadOf` configuration settings do not apply to `git submodule update --init` (and probably related) calls.

Is this intentional?

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).

Greetings, Stefan Schindler

On Thu, Jan 5, 2017 at 2:09 AM, Stefan Schindler <stsch@boxbox.org> wrote:

The original design of submodules was to have a submodule to be a standalone repository, such that e.g. its options are read from its own config file. So the original vision was to decouple the init and clone of the submodule to allow the user to change the settings:

    git submodule init
    # copies the submodule.<name>.URL from .gitmodules to .git/config
    # user realizes that the URL is not a good idea, such that
    git  config submodule.<name>.url http://${company-mirror}/submodule
    # now the url is fixed so
    git submodule update

I guess it could be a good idea to propagate some settings from the superproject to the submodules when they are cloned.

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.

On Thu, Jan 05, 2017 at 05:53:30AM -0800, Stefan Beller wrote:

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@gmail.com/

On Thu, Jan 5, 2017 at 9:02 AM, Jeff King <peff@peff.net> wrote:

Oh, yeah that was the difference.

AFAIK there were no such patches yet.

Or maybe we could specialize these patches to allow includes from specific other repos, i.e. superproject(s) or worktrees.