On Fri, Dec 11, 2020 at 02:24:35PM +0100, Patrick Steinhardt 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`. > > > > I agree with Ævar that we probably should keep an empty variable as the > > empty string. I think some options use an empty string to clear a list > > (e.g., push.pushOption), and I'm not sure how they'd react to a bool > > instead. It would be nice to also have a way to do the implicit-bool > > thing, but I don't think it's strictly necessary (it's always correct to > > put the string "true" into the variable instead). > > I think this is just weirdly worded in the `-c` case, which I mostly > copied. We _do_ keep the empty string, which effectively means that `git > config --type=bool` will return `false`. Oh indeed, I misread what you wrote in the documentation. I think it is doing the right thing, then. IMHO it is not worth even calling out specially, since there is no matching implicit-bool form. I.e., I'd probably just cut the final sentence. > Or do you mean that we should allow `--config-env=foo.bar=`? Hmm, yeah, that would work as an "implicit bool". But it's sufficiently ugly and non-intuitive (and weirdly overlapping with "-c") that I'm not sure it is worth supporting. -Peff
