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 -- 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