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

[Jeff King <peff@peff.net>]

On Fri, Sep 24, 2021 at 02:28:29PM -0700, Junio C Hamano wrote:

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

Yeah, see my comments later in that mail. :)

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

Yeah, as long as we leave the door open syntactically, I think it is OK.

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

Whoops, that should have been "envIs", asserting that $FOO contains
"bar".

As I said, I think it matters more with the infix operators, as:

  [includeIf "env:FOO == bar"]

is more readable than:

  [includeIf "env:FOO==bar"]

But I do think:

  [includeIf "envIs:FOO:bar"]

is harder to read than even:

  [includeIf "envIs:FOO: bar"]

-Peff