On Wed, Nov 25, 2020 at 05:41:14AM -0500, Jeff King wrote:
> On Tue, Nov 24, 2020 at 11:50:46AM +0100, Patrick Steinhardt wrote:
> 
> >     - I've changed priorities. The envvars are treated as command-level
> >       and as such override all values configured in files. But any
> >       explicit `git -c key=value` will now override these envvars.
> 
> That ordering makes sense. Those get passed through the environment,
> too, but at some point there is a process where your new ones are in the
> environment and the "-c" ones are on the command-line.
> 
> I do still think that a "--config-env" option solves your problem in a
> much simpler way (especially in terms of interface we expose to users
> that we'll be locked into forever). I sketched out the solution below if
> it's of interest (and I'd be happy to polish it up, or hand it off to
> you if so). But if you're unconvinced, I'll stop mentioning it.

The thing I like more about using envvars only is that you only need to
modify a single part, while with `--config-env` there's two moving
parts. E.g. assume you have a script and want certain configuration to
apply to all git commands in that script. It's trivial in the envvar
case, while for `--config-env` you'll also have to modify each single
git call. You could get around that by using a wrapper, but it's still a
tad more involved. A second thing I briefly wondered about is the
maximum command line length, which may be easier to hit in case you want
to pass a lot of config entries.

None of these complaints apply to my original usecase, where
`--config-env` would work equally well. But I do think that for
scripting use, which is going to be most of all cases where my patch
series is useful, GIT_CONFIG_COUNT is easier to use.

There probably are good arguments for `--config-env`, for example that
it's easier to spot when executing a git command. I stil lean towards my
current implementation, but I'm obviously biased. So if there is
consensus that we should use `--config-env` instead, I'm not opposed.

Patrick