On Wed, Dec 09, 2020 at 03:40:17PM +0100, Ævar Arnfjörð Bjarmason wrote: > > +--config-env=<name>=<envvar>:: > > + Pass a configuration parameter to the command. The <envvar> > > + given will be replaced with the contents of the environment > > + variable of that name. In contrast to `-c`, an envvar must > > + always be given and exist in the environment. Passing an > > + environment variable with empty value will set <name> to the > > + empty string which `git config --type=bool` will convert to > > + `false`. > > Okey, because "-c foo.bar" (true) "-c foo.bar=" is the empty string, but > that doesn't make sene with "--config-env". Also the whole part about > --type=bool is just confusing, because it's referring to `-c`'s magic > behavior when it comes to `bool` which we don't have here. Yeah, I agree. > I think it's also worth describing what this is for & what the > limitations are. Maybe: Agreed, and the text you gave looks reasonable. Another reason to use it is that it will (if we add the patches I just sent on top) avoid the key/value ambiguity with equals in the section name. > Not something new, and maybe not something for this series, but I wish > -c and --config-env would document this limitation that we support "=" > in keys in config, but not via those parameters. Yeah. If we add in my patches, then the limitation is gone here (but we should mention the limitation on the environment variable name). I stopped short of adding a variant of "-c" that avoids the ambiguity. I'm certainly not opposed to one if somebody wants to do it, but I think documenting the current limitation makes sense in the meantime (and we should do it in this series while we're thinking about it). -Peff
