Subject: Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate

From: Jeff King <[email-masked]>
Date: Sat, 21 Mar 2015 09:22:59 -0400

On Tue, Mar 10, 2015 at 09:56:42PM +1300, Jens Lehmann wrote:

> >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.
> 
> I tend to rather not share configs. While I agree that for the example
> which started this it would be correct to simply pass http.sslverify,
> that doesn't always make sense (e.g. it never does for a setting like
> core.worktree).
> 
> We already have two options for submodule add and update that are
> passed to the clone command (--reference & --depth), maybe it is time
> to add another one for passing config options to clone (which then get
> set permanently in the submodule's config).

Sorry, I missed this earlier, as it fell into a spam trap.

What you're proposing does make sense to me. We already have "git clone
-c", so I think it would just be a matter of passing along that option
in the submodule code.

-Peff