Re: [PATCH] config: add an includeIf.env{Exists,Bool,Is,Match}
- From
Jeff King <peff@peff.net>
- Date
- Sep 24, 2021, 21:59 UTC
- Message-ID
- <YU5KOpGkS5sH4iFJ@coredump.intra.peff.net>
- In-Reply-To
- <xmqqa6k1slxe.fsf@gitster.g>
On Fri, Sep 24, 2021 at 02:28:29PM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> > 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. :)
Show 6 quoted lines
> > 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.
Show 8 quoted lines
> > 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