# 'git submodule update' ignores [http] config 3 messages from 2018-08-09 to 2018-08-10. Participants: Jonathon Reinhart, Jonathan Nieder. Thread: https://gitlist.dev/t/49087 ## Jonathon Reinhart, 2018-08-09 22:50 Subject: 'git submodule update' ignores [http] config Message-ID: URL: https://gitlist.dev/e/CAPFHKzepqebXX7mrbeoc%3D%2BSHzWZ5N%2B6eOaLiC26tVGKogZoLGg%40mail.gmail.com ``` 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:@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:@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: * * 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 ``` ## Jonathan Nieder, 2018-08-10 03:06 Subject: Re: 'git submodule update' ignores [http] config Message-ID: <20180810030624.GA101965@aiede.svl.corp.google.com> URL: https://gitlist.dev/e/20180810030624.GA101965%40aiede.svl.corp.google.com In-Reply-To: ``` +cc: Stefan, who has been looking at fetch --recurse-submodules recently Hi, Jonathon Reinhart wrote: > 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 [...] > C:\Users\jreinhart\testrepo>set GIT_CURL_VERBOSE=1 > C:\Users\jreinhart\testrepo>git fetch [...] > * CAfile: C:\Users\gitlab-runner\builds\deadbeef\0\somegroup\someproj.git\CA_SERVER_TLS_CA_FILE [...] > C:\Users\jreinhart\testrepo>git checkout master > C:\Users\jreinhart\testrepo>git submodule update --init [...] > * CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt [...] > Note that the CAfile reverted to its default instead of using the same > one from the `git fetch`. 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 ``` ## Jonathon Reinhart, 2018-08-10 17:02 Subject: Re: 'git submodule update' ignores [http] config Message-ID: URL: https://gitlist.dev/e/CAPFHKze39tDyVVMg%3Dop9RKty7OgWnscww7JvXAByNU7JxJJfLQ%40mail.gmail.com In-Reply-To: <20180810030624.GA101965@aiede.svl.corp.google.com> ``` 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 > > +cc: Stefan, who has been looking at fetch --recurse-submodules recently > Hi, > > Jonathon Reinhart wrote: > > > 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 > [...] > > C:\Users\jreinhart\testrepo>set GIT_CURL_VERBOSE=1 > > C:\Users\jreinhart\testrepo>git fetch > [...] > > * CAfile: C:\Users\gitlab-runner\builds\deadbeef\0\somegroup\someproj.git\CA_SERVER_TLS_CA_FILE > [...] > > C:\Users\jreinhart\testrepo>git checkout master > > C:\Users\jreinhart\testrepo>git submodule update --init > [...] > > * CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt > [...] > > Note that the CAfile reverted to its default instead of using the same > > one from the `git fetch`. > > 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 ```