Glen Choo <chooglen@xxxxxxxxxx> writes: > > +`hasconfig:remote.*.url:`:: > > + The data that follows this keyword is taken to > > + be a pattern with standard globbing wildcards and two > > + additional ones, `**/` and `/**`, that can match multiple > > + components. The first time this keyword is seen, the rest of > > + the config files will be scanned for remote URLs (without > > + applying any values). If there exists at least one remote URL > > + that matches this pattern, the include condition is met. > > ++ > > +Files included by this option (directly or indirectly) are not allowed > > +to contain remote URLs. > > Wondering out loud.. Reading this and Ævar's comment [1], I wonder if we > should make it clear to users *why* we choose to forbid remote URLs. > > Since this series is setting a precedent for future "hasconfig:" > conditions (files included by "hasconfig:foo.*.bar" cannot contain any > "foo.*.bar" values), it would be useful to git developers to explain > *why* we chose to do this. And if we're documenting it for ourselves, > we might as well write it in the public docs. That way, users would know > that this is more of a guardrail (because it's simpler to understand > this way) than a hard limitation. > > [1] https://lore.kernel.org/git/211207.86k0ggnvfo.gmgdl@xxxxxxxxxxxxxxxxxxx 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.
