On Mon, Sep 27 2021, Jeff King wrote:
On Tue, Sep 28, 2021 at 01:52:26AM +0200, Ævar Arnfjörð Bjarmason wrote:
quoted
An implicit assumption of mine in the simpler positive-match-only
version (which I should have made clear) is that anyone who needs this
sort of complexity can just arrange to wrap their "git" in a function,
or do this sort of thing in their ~/.bashrc, i.e. just:
if code_of_arbitrary_complexity
then
export GIT_DO_XYZ_INCLUDES=1
fi
Then in your config:
includeIf.envBool:GIT_DO_XYZ_INCLUDES.path=~/.gitconfig.d/xyz.cfg
And having written that out I think the best thing to do is probably to
have a version that only does the envExists and envBool version (or just
envBool), and skip envIs and envMatch entirely.
I'm not sure I agree. If you are willing to wrap git, then you can just
add:
git -c include.path=~/.gitconfig.d/xyz.cfg
to the command-line in the first place. Or if you're willing to use our
undocumented interface, you can even do it in your .bashrc:
if code_of_arbitrary_complexity
then
GIT_CONFIG_PARAMETERS="'include.path'='~/.gitconfig.d/xyz.cfg'"
fi
Sort of, that'll give you unconditional inclusion, but won't e.g. handle
a case where the env include only runs in some .git/config, or depending
on other inclusion (e.g. in ~/dev/git, but only if XYZ env var).
But yeah, it won't handle all potential cases. I figured for this sort
of thing it was better to start small and see if the provided interface
was enough..
The value of this env matching is that it is done at run-time without
wrapping, and can meaningfully inspect the state of the world. E.g., the
$TERM thing that started this thread.
Yeah, maybe we should have at least an ifStrEQ, whatever we call it...
quoted
In the case of env:PATH we're just setting users up for some buggy or
unexpected interaction with something that would be better done either
via a gitdir include, or if they really need $PATH they can just wrap
"git" in a function that sets a boolean inclusion variable.
Yes, I have trouble imagining why any matching on env:PATH would be
useful (or $PWD, since we have the much less confusing gitdir
conditional). Which isn't to say I want to forbid it, but just because
people can shoot themselves in the foot with complexity doesn't mean
that "envIs" is a bad thing when it's not misused.
I'm biased by past on-list discussions where existing behavior, no
matter if unintentional or emergent can be really hard to fix once
established.
quoted
quoted
I think it's just the mashed-up colons that I find ugly in the first
one. But I agree the latter isn't that nice either, and introduces the
ambiguity you describe.
FWIW I hacked up a --config-key --config-value pairing so you could set
keys with "=" in them on the command-line, I'm not sure I like the
interface, but it gets rid of that ":" v.s. "=" edge case:
https://github.com/avar/git/commit/a86053df48b
Yeah, we talked about that a while ago, but nobody liked the interface
enough to actually code it (and as far as I know, it's really
theoretical; nobody has actually wanted to set such an option from the
command-line yet, and we have the --config-env stuff for people who want
to robustly pass along arbitrary keys).
A perhaps more subtle but less awkward to type version is to just
require two arguments, like:
git --config <key> <value> ...
I suppose --config would work like that, you can'd to it with "-c". I
think it's more confusing to have a "-c" and "--config" which unlike
most other things don't follow the obvious long and short option names
working the same way.
but I'd just as soon continue to leave it un-implemented if nobody has
actually needed it in practice.
*nod*. I do think it's bad design to introduce an "env" inclusion
feature that relies on "=" though while we don't have something like
that, i.e.
I think we should probably not add that --config-{key,value}, but
avoiding the arbitrary limitation of not being able to specify certain
config keys seems prudent in that case, and since the "=" v.s. ":" is
only an aesthetic preference I think being able to compose things
without limitations wins out.
We do have the "=" key limitation now, but I don't think it's there for
any key we currently define, except things like "url.<base>.insteadOf"
if the "<base> has a "=" in it (and maybe just that one).