> > As for the config pairs, they are currently being
> > passed through - do you have a situation in mind in which they should
> > not be passed through?
>
> Wasn't the GIT_CONFIG_KEY/VALUE meant as a moral equivalent of the
> GIT_CONFIG_PARAMETERS for those scripts that do not want to bother
> following the quoting rules of the single parameter approach?
>
> I do not see why we should filter configuration variables passed via
> one mechanism and let variables passed via the other machanism
> through. That feels inconsistent (I suspect that there may already
> be inconsistencies introduced when GIT_CONFIG_KEY/VALUE mechanism
> was added, though).
Yes, I think you're right. The filter was added in 14111fc492 ("git:
submodule honor -c credential.* from command line", 2016-03-01) (letting
a sanitized version of GIT_CONFIG_PARAMETERS through) and took its
present form in 89044baa8b ("submodule: stop sanitizing config options",
2016-05-06) (removing the sanitization). GIT_CONFIG_KEY/VALUE was only
added in d8d77153ea ("config: allow specifying config entries via envvar
pairs", 2021-01-15).
Reading the commit messages of these commits, I agree that
GIT_CONFIG_KEY/VALUE should be treated the same way as
GIT_CONFIG_PARAMETERS. In particular, 14111fc492 mentioned passing
credentials as the reason for the feature, and in d8d77153ea, the
ability to pass secrets without exposing them to a user running "ps" was
one of the motivating reasons. I'll add a commit changing this before
this commit.
