Jeff King <p...@peff.net> writes:
> That was how I had originally envisioned the namespace working when I
> introduced include.path long ago. And I think Duy's v1 used that, but
> the feedback was that it was not sufficiently obvious that the
> subsection was a conditional.
I am not sure about "obviousness", but I agree that we do not know
that "conditional include" would be the only thing we want for the
second level for "include.path" directive. "include-if.<cond>.path"
is better for that reason.
I presume that you could still do
[include "if:gitdir=$path"]
path = ...
i.e. design the second level to begin with a token that tells
readers what it means (and assign "if:" token for "conditional
include"), but I do not think it is worth it.
I also imagine that
[include]
condition = ...
path = ...
is easier to read and write by end-users, but it probably is not
feasible because it requires too invasive change to the current code
to teach it to grok such construct.
Between "include-if" and "includeIf", if people find the latter not
too ugly, I'd prefer to keep it the way Duy posted. Because of the
way "include.path" and "include-if.<cond>.path" work, we can declare
that they are not like ordinary configuration variable definition
at all but are higher-level directives and that may be a sufficient
justification to allow "-" in its name, though, if people find
"includeIf" too ugly a name to live.
