Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: >> variables we read without the includeIf directive", with variations >> of "condition" including >> >> - a literal X is among the values of multi-valued variable Y. >> - a pattern X matches one of the values of multi-valued variable Y. >> - a literal Y is the name of an existing configuration variable. >> - a pattern Y matches the name of an existing configuration variable. > ... > code), in this case, unless there is another use case for this, I think > we should proceed with the use case that we know about first > (conditional include of a file supplied by a remote repo administrator). Doing it that way without thinking flexibility through will paint us into a corner, from which we cannot get out of, doesn't it? People will start asking "Why should we even have 'hasremoteurl:$URL' variant in 'includeIf' conditions, when one of the 'variableExists:Y' and friends can express the same thing", somebody new who is not yet in this community today will propose deprecating hasremoteurl in favor of more generalized approach and we have to give a sad answer "no, we earlier made a mistake of starting with a special case variant for expediency's sake, without thinking the general cases through. Because existing users depend on it, we have to support it til the end of time." We have the same regret with "why do we need grep.extendedRegexp when grep.patternType suffices?" I am reluctant to see us knowingly commit the same mistake here, unless there is a very good reason.
