Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 0c0e6b859f..e0e5ca558e 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -159,6 +159,22 @@ all branches that begin with `foo/`. This is useful if your branches are > organized hierarchically and you would like to apply a configuration to > all the branches in that hierarchy. > > +`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
