Jeff King <peff@xxxxxxxx> writes: > It's definitely sufficient, it's just annoying if a user shows up every > week and says "I want X.Y", and then somebody else shows up a week later > and says "I want X.Z". > > Are we serving any purpose in vetting each one (and if so, what)? Personally I do not think we would need to filter _anything_ if we can tell that the user directly said git -c var1=val1 -c var2=val2 $cmd ... and "git $cmd" ended up needing to spawn another "git" subcommand, possibly in some other repository (i.e. "$cmd" in this case is likely to be "submodule", but in principle it does not have to be). If the user somehow gives variables like core.worktree that are inappropriate to be applied across repositories, that's user's problem, i.e. "don't do it then if it hurts". If we are doing any filtering, however, it is always hard, if not impossible, to take away what we originally granted, even by mistake, for any reason, even for correctness or for security, in a later release. We probably could sidestep it by introducing an end-user configurable "whitelist" somewhere. -- 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