Junio C Hamano <gitster@xxxxxxxxx> writes: > Here is just a design level comment, without trying to outline the > implementation in my head like I usually do before making any > suggestion, but it strikes me somewhat sad that config.c needs to > know specifically about "remote_url". > > I wonder if this can be a more generalized framework that allows us > to say "we introduce a new [includeIf] variant to get another file > included only if some condition is met for the configuration > 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. > > If that is done, I would imagine that the feature can become a thin > specialization e.g. "there is an existing configuration variable > whose name is 'remotes.https://github.com/janathantanmy/git.url'" > > Perhaps I am dreaming? > > Thanks. I think that the hard part of this is how to present this to the end user - right now, we just have one pattern of variable (remote.*.url, where "*" is a wildcard) and one pattern of value with specific properties (e.g. this is a glob, not a regular expression, and the special value "**" is supported). Once we figure that out, I would think that we could implement it in a way similar to this patch. As for whether we should wait until the full feature before merging any code that does includeIf based on a variable (in order to avoid having code that would quickly be replaced by other 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).
