Re: [PATCH 2/2] config: allow specifying config entries via envvar pairs

On Wed, Nov 18, 2020 at 02:25:32AM +0000, brian m. carlson wrote:

On 2020-11-18 at 01:59:07, Jeff King wrote:

quoted

Yes, I think concatenating uri_encode(key) + "=" + uri_encode(value)
would be easier to reason about, and solves the ambiguity problem. If we
are willing to break from the existing format, it's probably a
reasonable direction.

We'll have to deal with embedded NULs, but other than that it seems
robust and easy to reason about.  I like the proposal below better,
though.

This would be easy enough to handle and fixes all the problems I
currently have.

quoted

I wondered at first how this is different from:

  git -c a.b.c=value foo

but I guess it is meant to do the same environment-lookup? We could
probably add:

  git --env-config a.b.c=ENV_VAR foo

to have Git internally stick $ENV_VAR into $GIT_CONFIG_PARAMETERS. That
avoids all of the rev-parse rigamarole, keeps the format of the
environment variable opaque, and solves Patrick's problem of putting the
value onto the command-line.

Sure, that could be an option.  It's the simplest, and we already know
how to handle config this way.  People will be able to figure out how to
use it pretty easily.

At first, this idea sounds quite interesting. But only until one
realizes that it's got the exact same problem which I'm trying to solve:
there's still a point in time where one can observe config values via
the command line, even though that moment now is a lot shorter compared
to running the "real" git command with those keys.

quoted

It doesn't solve the ambiguity with "=" in the subsection, but IMHO that
is not all that important a problem.

I'm fine with saying that we don't support environment variable names
with equals signs and just going with that.  It solves the ambiguity
problem and I'm not sure that they could usefully work on Unix anyway.

Moreover, people usually use the unrestricted data in the second chunk
for URLs, which shouldn't have unquoted equals signs.  You could
technically name other second fields that way, but why would you when
you could just not?

So I'm not too worried about it either way.

There's not only URLs though, but also paths in 'includeIf.*.path'.
Sure, it's unlikely that paths have an equals sign embedded. But I think
we should try to not paint ourselves into a corner.

This problem also would be nicely solved by URI-encoding both key and
value and then passing it via GIT_CONFIG_PARAMETER.

Patrick