Re: [PATCH v2 0/2] config: allow specifying config entries via envvar pairs
- From
Jeff King <peff@peff.net>
- Date
- Nov 26, 2020, 00:36 UTC
- Message-ID
- <X774nvXcRrP64SZ2@coredump.intra.peff.net>
- In-Reply-To
- <X75ZNv/8X5Z7Yfci@ncase>
On Wed, Nov 25, 2020 at 02:16:38PM +0100, Patrick Steinhardt wrote:
Show 15 quoted lines
> > 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