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
