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

[Jeff King <peff@peff.net>]

On Wed, Nov 25, 2020 at 02:16:38PM +0100, Patrick Steinhardt wrote:

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

Yeah, that's true. I haven't typically run across this myself because
usually such a script ends up invoked by git itself. I.e., it is
git-foo, and then I do:

  git -c some.var=value foo

which puts everything in the environment, but it's done by Git itself,
so the exact environment format remains opaque.

-Peff