On 2020-11-25 at 10:41:14, 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. Yeah, I agree this would be the right way to go. > 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. I do rather prefer this approach over the multiple key-value pairs. I think the use case of scripts could probably be easily solved with an additional environment variable like so: args="--config-env abc.def=GHI --config-env jkl.mno=PQR" This isn't necessarily super elegant, but I like it more than needing to handle many key-value pairs. But while I do have a moderately strong preference, I'm not going to argue for blocking the series if you still want to go this way. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature