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

From: Jonathan Tan <jonathantanmy@google.com>
Date: Jun 9, 2021, 18:15 UTC
Message-ID: <20210609181507.2400682-1-jonathantanmy@google.com>
In-Reply-To: <xmqqo8cfk3nk.fsf@gitster.g>

Show 13 quoted lines

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