Re: Bug? git submodule add SSL certificate problem: unable to get local issuer certificate
- From
Jeff King <peff@peff.net>
- Date
- Mar 21, 2015, 13:22 UTC
- Message-ID
- <20150321132259.GA11843@peff.net>
- In-Reply-To
- <54FEB1CA.7020204@web.de>
On Tue, Mar 10, 2015 at 09:56:42PM +1300, Jens Lehmann wrote:
Show 23 quoted lines
> >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