On Thu, Mar 05, 2015 at 04:20:10PM +0100, Aschemann Gerd wrote: > seems to be a bug: If adding a submodule from an https URL with a certificate issued by StartSSL (or even a private/self-signed one?) leads to the following error: > > $ git -c http.sslverify=false submodule add https://example.com/git/xxx.git > Cloning into 'xxx'... > fatal: unable to access 'https://example.com/git/xxx.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none > Clone of 'https://example.com/git/xxx.git' into submodule path 'xxx' failed > > Performing a simple clone works well: > > $ git -c http.sslverify=false clone https://example.com/git/xxx.git > Cloning into 'xxx'... > Password for 'https://example.com': I think the problem is that the submodule code wipes all "local" environment variables before executing the submodule clone, and that includes the variable containing command-line config. Config like this is in a funny boat. We do not want it to cross transport boundaries, so that if we run: git -c foo=bar clone /some/local/path the process serving /some/local/path should not see the "foo" option[1]. But for submodules in the same repository, keeping the shared config is probably more reasonable (I can imagine a config variable that you might want to behave differently between the submodule and the main project, but I could not think of any off-hand, and I expect it would be a rare exception). Submodule folks (cc'd) may have opinions. -Peff [1] This behavior comes from 655e8d9 (do not pass "git -c foo=bar" params to transport helpers, 2010-08-24), and the original discussion is here: http://thread.gmane.org/gmane.comp.version-control.git/154241/focus=154255 I am tempted to simply drop the transport-layer blocking of config options. It is not buying us anything security-wise, and it could actually be convenient to pass options to the "other side". But it's probably a bad idea, if only because it would not be consistently applied to repos on the other side of git://, http://, or ssh sessions. So the sanest fix, if we want submodules to inherit the command-line config, would be to drop GIT_CONFIG_PARAMETERS from local_repo_env, and have the transport code suppress it manually. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html