Jeff King <peff@xxxxxxxx> 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"?
