Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > The explanation is rather long, though. It goes something like this: > > If the main config is: > > [remote a] > url = bar > [includeif hasconfig:remote.*.url:foo] > path = foo > [includeif hasconfig:remote.*.url:bar] > path = bar > > and "bar" contains: > > [remote b] > url = foo > > Should "foo" be included? For now, we avoid these situations > completely by prohibiting URLs from being configured in "includeif > hasconfig". > > If you can think of a concise explanation, maybe we can include it. Perhaps it is easier to approach it from the viewpoint of a new user who is unfamiliar with what you designed. I would imagine that most users would find it natural if a single pass precedure read and processed lines as it sees them. That is, when the first includeif is evaluated, we have seen only 'remote.a.url' whose value is 'bar', so the condition does not hold. and then when the second includeif is evaluated, it gets included, and we read 'bar'. But that is wher configuration reading ends; remote.b.url is not asked for after we process the second includeif til the end. If you explain (1) why such a simplest design would not work well; and (2) how the actual design is different from that simplest design to overcome it. it would be easier to grok? Thanks.