Re: [PATCH v2 3/4] run-command: move envvar-resetting function

From: Jonathan Tan <jonathantanmy@google.com>
To: gitster@pobox.com
Cc: jonathantanmy@google.com, git@vger.kernel.org, me@ttaylorr.com,
	newren@gmail.com, emilyshaffer@google.com
Subject: Re: [PATCH v2 3/4] run-command: move envvar-resetting function
Date: Wed,  9 Jun 2021 11:15:07 -0700	[thread overview]
Message-ID: <20210609181507.2400682-1-jonathantanmy@google.com> (raw)
In-Reply-To: <xmqqo8cfk3nk.fsf@gitster.g>

> > 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.