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
