From: Jonathan Tan <jonathantanmy@google.com>
To: gitster@pobox.com
Cc: jonathantanmy@google.com, git@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] config: include file if remote URL matches a glob
Date: Wed, 13 Oct 2021 12:52:45 -0700 [thread overview]
Message-ID: <20211013195245.93145-1-jonathantanmy@google.com> (raw)
In-Reply-To: <xmqqk0ih24a0.fsf@gitster.g>
> Jonathan Tan <jonathantanmy@google.com> writes:
>
> > I marked this as RFC because there are some design points that need to
> > be resolved:
> >
> > - The existing "include" and "includeIf" instructions are executed
> > immediately, whereas in order to be useful, the execution of
> > "includeIf hasremoteurl" needs to be delayed until all config files
> > are read. Are there better ways to do this?
>
> An interesting chicken-and-egg problem. Even if an included
> configuration file does not have further "include", you may discover
> there are more remotes, which may add new includes to fire from the
> top-level configuration file.
That's true. We might need to say that such conditional includes are
based only on what happened during the main config parsing.
> What if we have multiple remotes? Is it a sufficient match for only
> one of them match what is mentioned in the includeIf condition?
> Should all of them must match the pattern instead? Majority,
> perhaps? Something else?
I think at least one remote should match.
> > - Is the conditionally-included file allowed to have its own
> > "include{,If}" instructions? I'm thinking that we should forbid it
> > because, for example, if we had 4 files as follows: A includes B and
> > C includes D, and we include A and C in our main config (in that
> > order), it wouldn't be clear whether B (because A was first included)
> > or C (because we should execute everything at the same depth first)
> > should be executed first. (In this patch, I didn't do anything about
> > includes.)
>
> Interesting. The order of real inclusion obviously would affect the
> outcome of the "last one wins" rule. And this does not have to be
> limited to this "hasremote" condition, so we need to design it with
> a bit of care.
>
> Would it be possible for a newly included file to invalidate an
> earlier condition that was used to decide whether to include another
> file or not? If not, then you can take a two-pass approach where
> the first pass is used to decide solely to discover which
> conditionally included files are taken, clear the slate and the
> parse these files in the textual order. In the case of your example
> above, the early part of the primary config would be the first to be
> read, then comes A's early part, then comes B in its entirety, then
> the rest of A, and then the middle part of the primary config, then
> C's early part, then D, and then the rest of C,... you got the idea.
>
> If it is possible for an included file to invalidate a condition we
> have already evaluated to make a decision, it would become messy.
> For example, we might decide to include another file based on the
> value we discovered for a config variable:
>
> === .git/config ===
> [my] variable
> [your] variable = false
>
> [includeIf "configEq:my.variable==true"]
> file = fileA
>
> but the included file may override the condition, e.g.
>
> === fileA ===
> [my] variable = false
> [your] variable = true
>
> and applying the "last one wins" rule becomes messy. I do not
> offhand know what these
>
> $ git config --bool my.variable
> $ git config --bool your.variable
>
> should say, and do not have a good explanation for possible
> outcomes.
In this case, it makes sense to me to think that files are included
entirely or not at all, so my.variable would be false and your.variable
would be true. I guess the tricky part is something like:
=== .git/config ===
[my] variable = true
[your] variable = false
[includeIf "configEq:my.variable==true"]
file = fileA
[includeIf "configEq:my.variable==false"]
file = fileB
=== fileA ===
my.variable = false
=== fileB ===
your.variable = true
and what my.variable and your.variable would end up being.
> Maybe the above example can serve as a way to guide us when we
> design the types of conditionals we allow in includeIf. This
> example tells us that it is probably a terrible idea to allow using
> values of configuration variables as part of "includeIf" condition.
Hmm...well, remote.foo.url is a configuration variable. I think that the
two-pass approach you describe would work if we prohibit subsequent
inclusions.
> There may lead to similar "'hasremoteurl' makes a well-behaved
> condition, because [remote] are additive and not 'last-one-wins',
> but we cannot add 'lacksremoteurl' as a condition, because a file we
> decide to include based on a 'lacks' predicate may invalidate the
> 'lacks' condition by defining such a remote" design decisions you'd
> need to make around the URLs of the remotes defined for the
> repository.
And if we implement two-pass with no subsequent inclusions, "lacks"
would work the same way.
next prev parent reply other threads:[~2021-10-13 19:52 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 22:57 [RFC PATCH 0/2] Conditional config includes based on remote URL Jonathan Tan
2021-10-12 22:57 ` [RFC PATCH 1/2] config: make git_config_include() static Jonathan Tan
2021-10-12 23:07 ` Jeff King
2021-10-12 23:26 ` Junio C Hamano
2021-10-13 8:26 ` Ævar Arnfjörð Bjarmason
2021-10-13 17:00 ` Junio C Hamano
2021-10-13 18:13 ` Jonathan Tan
2021-10-12 22:57 ` [RFC PATCH 2/2] config: include file if remote URL matches a glob Jonathan Tan
2021-10-12 23:30 ` Jeff King
2021-10-13 18:33 ` Jonathan Tan
2021-10-27 11:40 ` Jeff King
2021-10-27 17:23 ` Jonathan Tan
2021-10-12 23:48 ` Junio C Hamano
2021-10-13 19:52 ` Jonathan Tan [this message]
2021-10-13 0:46 ` [RFC PATCH 0/2] Conditional config includes based on remote URL brian m. carlson
2021-10-13 18:17 ` Jonathan Tan
2021-10-18 20:48 ` Jonathan Tan
2021-10-22 3:12 ` Emily Shaffer
2021-10-27 11:55 ` Jeff King
2021-10-27 17:52 ` Jonathan Tan
2021-10-27 20:32 ` Jeff King
2021-10-25 13:03 ` Ævar Arnfjörð Bjarmason
2021-10-25 18:53 ` Jonathan Tan
2021-10-26 10:12 ` Ævar Arnfjörð Bjarmason
2021-10-29 17:31 ` [WIP v2 " Jonathan Tan
2021-10-29 17:31 ` [WIP v2 1/2] config: make git_config_include() static Jonathan Tan
2021-11-05 19:45 ` Emily Shaffer
2021-10-29 17:31 ` [WIP v2 2/2] config: include file if remote URL matches a glob Jonathan Tan
2021-11-05 20:24 ` Emily Shaffer
2021-11-06 4:41 ` Ævar Arnfjörð Bjarmason
2021-11-09 0:25 ` Jonathan Tan
2021-11-09 0:22 ` Jonathan Tan
2021-11-16 0:00 ` [PATCH v3 0/2] Conditional config includes based on remote URL Jonathan Tan
2021-11-16 0:00 ` [PATCH v3 1/2] config: make git_config_include() static Jonathan Tan
2021-11-16 0:00 ` [PATCH v3 2/2] config: include file if remote URL matches a glob Jonathan Tan
2021-11-22 22:59 ` Glen Choo
2021-11-29 17:53 ` Jonathan Tan
2021-11-23 1:22 ` Junio C Hamano
2021-11-29 18:18 ` Jonathan Tan
2021-12-01 18:51 ` Junio C Hamano
2021-12-02 23:14 ` Jonathan Tan
2021-11-23 1:27 ` Ævar Arnfjörð Bjarmason
2021-11-29 18:33 ` Jonathan Tan
2021-11-29 20:50 ` Ævar Arnfjörð Bjarmason
2021-11-29 20:23 ` [PATCH v4 0/2] Conditional config includes based on remote URL Jonathan Tan
2021-11-29 20:23 ` [PATCH v4 1/2] config: make git_config_include() static Jonathan Tan
2021-11-29 20:23 ` [PATCH v4 2/2] config: include file if remote URL matches a glob Jonathan Tan
2021-12-02 6:57 ` Junio C Hamano
2021-12-02 17:41 ` Jonathan Tan
2021-11-29 20:48 ` [PATCH v4 0/2] Conditional config includes based on remote URL Ævar Arnfjörð Bjarmason
2021-11-30 7:51 ` Junio C Hamano
2021-12-02 23:31 ` [PATCH v5 " Jonathan Tan
2021-12-02 23:31 ` [PATCH v5 1/2] config: make git_config_include() static Jonathan Tan
2021-12-02 23:31 ` [PATCH v5 2/2] config: include file if remote URL matches a glob Jonathan Tan
2021-12-06 22:32 ` Glen Choo
2021-12-07 17:53 ` Jonathan Tan
2021-12-06 18:57 ` [PATCH v5 0/2] Conditional config includes based on remote URL Ævar Arnfjörð Bjarmason
2021-12-07 17:46 ` Jonathan Tan
2021-12-07 17:56 ` Ævar Arnfjörð Bjarmason
2021-12-07 18:52 ` Jonathan Tan
2021-12-07 23:23 ` [PATCH v6 " Jonathan Tan
2021-12-07 23:23 ` [PATCH v6 1/2] config: make git_config_include() static Jonathan Tan
2021-12-07 23:23 ` [PATCH v6 2/2] config: include file if remote URL matches a glob Jonathan Tan
2021-12-08 19:19 ` Glen Choo
2021-12-09 22:16 ` Jonathan Tan
2021-12-08 19:55 ` Glen Choo
2021-12-09 22:39 ` Jonathan Tan
2021-12-09 23:33 ` Glen Choo
2021-12-13 23:35 ` Jonathan Tan
2021-12-10 21:45 ` Junio C Hamano
2021-12-13 23:37 ` Jonathan Tan
2021-12-14 21:31 ` [PATCH v7 0/2] Conditional config includes based on remote URL Jonathan Tan
2021-12-14 21:31 ` [PATCH v7 1/2] config: make git_config_include() static Jonathan Tan
2021-12-14 21:31 ` [PATCH v7 2/2] config: include file if remote URL matches a glob Jonathan Tan
2021-12-16 21:54 ` Glen Choo
2021-12-28 0:55 ` Elijah Newren
2022-01-10 18:58 ` Jonathan Tan
2021-12-16 21:57 ` [PATCH v7 0/2] Conditional config includes based on remote URL Glen Choo
2021-12-28 1:13 ` Elijah Newren
2021-12-28 23:13 ` Glen Choo
2022-01-10 19:22 ` Jonathan Tan
2022-01-10 20:17 ` Elijah Newren
2022-01-25 13:26 ` Scalar vs JGit, was " Johannes Schindelin
2022-01-18 17:47 ` [PATCH v8 " Jonathan Tan
2022-01-18 17:47 ` [PATCH v8 1/2] config: make git_config_include() static Jonathan Tan
2022-01-18 17:47 ` [PATCH v8 2/2] config: include file if remote URL matches a glob Jonathan Tan
2022-01-18 20:54 ` [PATCH v8 0/2] Conditional config includes based on remote URL Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211013195245.93145-1-jonathantanmy@google.com \
--to=jonathantanmy@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).