Re: [PATCH v3 2/2] config: include file if remote URL matches a glob

From: Jonathan Tan <jonathantanmy@google.com>
Date: Nov 29, 2021, 18:18 UTC
Message-ID: <20211129181811.375318-1-jonathantanmy@google.com>
In-Reply-To: <xmqqtug3aco7.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 23 quoted lines

> 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).