Re: [PATCH v6 2/2] config: include file if remote URL matches a glob
Glen Choo <chooglen@google.com> writes:
Show 24 quoted lines
> > +`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@evledraar.gmail.com
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.