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:

quoted

quoted

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

quoted

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!

quoted

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