'git submodule update' ignores [http] config

I've been trying to track down an issue with the GitLab CI Runner: https://gitlab.com/gitlab-org/gitlab-runner/issues/3497

Note that I'm using "git version 2.7.2.windows.1".

I've narrowed it down to an observation that the [http] config seems to be ignored by 'git submodule update'. Shouldn't those options be respected by submodules?

Given a .git/config file like this:

------------------------------------------------------------------------
[fetch]
    recurseSubmodules = false
[http "https://gitlab.exmaple.com"]
    sslCAInfo =
C:\\Users\\gitlab-runner\\builds\\deadbeef\\0\\somegroup\\someproj.git\\CA_SERVER_TLS_CA_FILE
[core]
    ...
[remote "origin"]
    url = https://jreinhart:<private-access-token>@gitlab.example.com/somegroup/someproj.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[submodule "some-lib"]
    url = https://jreinhart:<private-access-token>@gitlab.example.com/somegroup/some-lib.git
------------------------------------------------------------------------

...I see the following results:

------------------------------------------------------------------------
C:\Users\jreinhart\testrepo>set GIT_CURL_VERBOSE=1
C:\Users\jreinhart\testrepo>git fetch
...
* Connected to gitlab.example.com (x.x.x.x) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: C:\Users\gitlab-runner\builds\deadbeef\0\somegroup\someproj.git\CA_SERVER_TLS_CA_FILE
  CApath: none
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  <certificate details here>
*        SSL certificate verify ok.
...
C:\Users\jreinhart\testrepo>git checkout master
C:\Users\jreinhart\testrepo>git submodule update --init
...
* Connected to gitlab.example.com (x.x.x.x) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
  CApath: none
* SSL certificate problem: unable to get local issuer certificate
...
------------------------------------------------------------------------

Note that the CAfile reverted to its default instead of using the same one from the `git fetch`.

Thanks in advance,

Jonathon Reinhart

+cc: Stefan, who has been looking at fetch --recurse-submodules recently Hi,

Jonathon Reinhart wrote:

[...]

[...]

[...]

[...]

[...]

Interesting.

The context is that "git submodule update" is simply running commands like "git fetch" inside the submodules, and the repository-local config of the superproject does not apply there.

In the long run, commands like "git fetch --recurse-submodules" may chaange to use a single process. It's possible that some of the repository-local configuration of the superproject would apply at that point, though the inconsistency would be confusing, so probably not these particular settings. Anyway, that's a faraway future; today, "git fetch --recurse-submodules" is also running "git fetch" commands inside the submodules, and the repository-local config of the superproject does not apply there.

Would it work for you to put this configuration in the global config file ("git config --global --edit")? That way, it would be used by all repositories. If you want it only to apply within the testrepo directory, you can use conditional includes --- something like:

  in $HOME/.git/config/testrepo-ca:

  [http "https://gitlab.example.com"]
  	sslCAInfo = ...

  in $HOME/.git/config/git:

  [includeIf "gitdir/i:~/testrepo/**"]
  	path = testrepo-ca

Thanks and hope that helps, Jonathan

Thanks Jonathan.

The confirmation that the super-project config does not apply to the submodules is what I was really looking for. We'll go from here.

This is a bit complicated, because this config is all generated dynamically by the GitLab CI Runner when it is setting up a build job. (See the linked issue in my first email for the gory details).

Thank you, Jonathon