Jeff King <p...@peff.net> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
