> On 25 Apr 2016, at 23:24, Jeff King <peff@xxxxxxxx> wrote: > > 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. This looks like a very promising solution and I can't think of a security problem either (I checked the older thread [1] you referenced, too)! I got my Git-LFS use case working with the patch below. For me it was necessary to export GIT_CONFIG_PARAMETERS to make it available to the Git process if the process is invoked as follows [2]: (sanitize_submodule_env; cd "$sm_path" && git <something>") Exporting the variable would not be necessary in this case: (cd "$sm_path" && sanitize_submodule_env git <something>") Unfortunately that does not work and I think the reason is that clear_local_git_env (invoked by sanitize_submodule_env) clears the $GIT_DIR, too. If there is a reason against exporting GIT_CONFIG_PARAMETERS, then this would work, too: (sanitize_submodule_env; cd "$sm_path" && GIT_CONFIG_PARAMETERS=$GIT_CONFIG_PARAMETERS git <something>) Would the patch below be an acceptable solution? Thanks, Lars [1] http://thread.gmane.org/gmane.comp.version-control.git/264840 [2] https://github.com/git/git/blob/3ad15fd5e17bbb73fb1161ff4e9c3ed254d5b243/git-submodule.sh#L811 diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c index 3bd6883..9231089 100644 --- a/builtin/submodule--helper.c +++ b/builtin/submodule--helper.c @@ -129,6 +129,8 @@ static int submodule_config_ok(const char *var) { if (starts_with(var, "credential.")) return 1; + if (starts_with(var, "filter.")) + return 1; return 0; } diff --git a/git-submodule.sh b/git-submodule.sh index 2a84d7e..b02f5b9 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -199,7 +199,7 @@ sanitize_submodule_env() { sanitized_config=$(git submodule--helper sanitize-config) clear_local_git_env - GIT_CONFIG_PARAMETERS=$sanitized_config + export GIT_CONFIG_PARAMETERS=$sanitized_config } # -- 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