Subject: Re: [PATCH] config: add an includeIf.env{Exists,Bool,Is,Match}

From: Junio C Hamano <[email-masked]>
Date: Fri, 24 Sep 2021 14:28:29 -0700

Jeff King <[email-masked]> writes:

> I had thought to extend with the operator, like:
>
>   # equality
>   [includeIf "env:FOO==value"]
>   # regex
>   [includeIf "env:FOO=~v[a]l"]

Yup, that matched my aesthetics better ;-)

> But as you note, "=" is somewhat problematic, and without that we can't
> use the "usual" operators. Plus there's no usual operator for globbing. ;)
> So embedding it in the name is fine by me (and mostly a bikeshed thing
> anyway).

Perhaps.  I am not sure if we deeply care about "git -c var=val" in
this case, especially since this is part of includeif, though.  It
may be more important to keep the syntax useful and extensible for
everyday use than for one-off "git -c" testing.

> I agree we don't really need a "/i" variant here.

Case insensitive environment variable names, no, but case
insensitive matching of values, maybe?  But I'd be happy to see us
start very minimally (even just envEQ alone without any other
frills, or optionally envNE to negate it, would be fine by me).

> Should we allow whitespace around key names and values? E.g.:
>
>   [includeIf "env: FOO: bar"]
>
> is IMHO more readable (even more so if we had infix operators like
> "==").

This asserts what? FOO=" bar"?