On Thu, Jan 5, 2017 at 2:09 AM, Stefan Schindler <stsch@xxxxxxxxxx> wrote:
> 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?
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.
>
> 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.
> Greetings,
> Stefan Schindler