On Mon, Apr 25, 2016 at 01:59:03PM -0700, Jacob Keller wrote: > >> However, I noticed that git config command line instructions such as > >> "-c filter.lfs.smudge=" are not passed to Git submodule operations. Thus > >> this does not work as expected: > >> > >> git -c filter.lfs.smudge= -c filter.lfs.required=false clone --recursive <url> <path> > > > > I have cc'd Jacob Keller, who authored origin/jk/submodule-c-credential, > > which does work in that area (deciding which config option to pass down > > into the submodule commands). > > > > This is a tricky question. The problem is that some configurations are > obviously not intended to go into the submodules, but determining how > is somewhat troublesome. There was some discussion on this previous > thread when we added support for credential options to pass through. Right. I think it may be reasonable to pass through filter.* in the whitelist. They are not activated without a matching .gitattributes entry in the repository (and people would generally configure them in their user-level ~/.gitconfig for that reason). It does mean that somebody would be stuck who really wanted to run the smudge filter in their local repo, but for some reason not in the subrepos. I am trying to think of a case in which that might be security-relevant if you didn't trust the sub-repos[1]. But I really don't see it. The filter is arbitrary code, but that's specified by the user; we're just feeding it possibly untrusted blobs. -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