On Wed, Dec 09, 2020 at 11:24:03AM -0500, Jeff King wrote:
> 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.

Yeah, I'll pick up the explanation by Ævar, it's a lot better compared
to what I had. Thanks!

> > 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

Do you want me to adopt your patches as part of this series?

Patrick