{"thread":{"id":"65770","subject":"[PATCH 0/3] config: allow disabling config includes","startedAt":"2026-06-08T13:57:09Z","lastAt":"2026-06-17T20:22:44Z","messageCount":14,"participants":["Derrick Stolee via GitGitGadget","Patrick Steinhardt","Derrick Stolee","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"544927","messageId":"pull.2139.git.1780927027.gitgitgadget@gmail.com","threadId":"65770","inReplyTo":null,"subject":"[PATCH 0/3] config: allow disabling config includes","fromName":"Derrick Stolee via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-06-08T13:57:03Z","receivedAt":"2026-06-08T13:57:09Z","isPatch":true,"body":"This series introduces a new way to ignore config include directives via two\nmechanisms:\n\n * GIT_CONFIG_INCLUDES=0 in the environment.\n * git --no-includes ... in the command line.\n\nMy motivation is from a tricky situation where users want to do the risky\nthing and include a repo-tracked file for sharing aliases and other\nrecommended config. They are then struggling in a later build step that is\nrunning Git commands (under a tool we don't control and can't change) that\nthen cause filesystem accesses outside of the build system's sandbox.\n\nWhile git config has a --no-includes option, that doesn't impact the\nbehavior of other Git commands. We build upon that existing logic for\ndisabling includes, though.\n\nHaving had recent luck recommending GIT_ADVICE=0 when running Git commands\nfrom third-party tools, I thought that a similar environment variable to\ndisable this functionality would be helpful, too.\n\nOne thing I do worry about is whether or not this would cause a significant\nbreak in behavior, or if this is a relatively safe thing to allow.\n\nThe three patches are organized as follows:\n\n 1. Patch 1 has a small typo fix in the config documentation that messes\n    with the format of the bulleted list. I include it here because I add to\n    that list in patch 2.\n 2. Patch 2 adds the environment variable and tests it via 'git config' and\n    the use of a Git alias.\n 3. Patch 3 adds the '--no-includes' option at the top level.\n\nThanks, -Stolee\n\nDerrick Stolee (3):\n  git-config.adoc: fix paragraph break\n  config: add GIT_CONFIG_INCLUDES\n  git: add --no-includes top-level option\n\n Documentation/git-config.adoc |  7 ++++++-\n Documentation/git.adoc        |  6 +++++-\n config.c                      |  7 ++++++-\n environment.h                 |  6 ++++++\n git.c                         |  6 +++++-\n t/t1305-config-include.sh     | 35 +++++++++++++++++++++++++++++++++++\n 6 files changed, 63 insertions(+), 4 deletions(-)\n\n\nbase-commit: 9ac3f193c05c2237e2b14ebaa1149e9fc8a1abe0\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-2139%2Fderrickstolee%2Fconfig-include-override-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2139/derrickstolee/config-include-override-v1\nPull-Request: https://github.com/gitgitgadget/git/pull/2139\n-- \ngitgitgadget\n"},{"id":"544928","messageId":"c996ef0b06faf83ffcc4559833a31d0e529a1905.1780927027.git.gitgitgadget@gmail.com","threadId":"65770","inReplyTo":"pull.2139.git.1780927027.gitgitgadget@gmail.com","subject":"[PATCH 1/3] git-config.adoc: fix paragraph break","fromName":"Derrick Stolee via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-06-08T13:57:04Z","receivedAt":"2026-06-08T13:57:10Z","isPatch":true,"body":"From: Derrick Stolee <stolee@gmail.com>\n\nThe bulletted list about environment variables is missing a '+' between\nsome paragraphs that belong to the same bullet item. Without it, the\nbulletted list is rendered as two separate lists with \"See also FILES.\"\nas a normal paragraph between them. Adding '+' unifies the lists.\n\nSigned-off-by: Derrick Stolee <stolee@gmail.com>\n---\n Documentation/git-config.adoc | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-config.adoc b/Documentation/git-config.adoc\nindex 00545b2054..044d776613 100644\n--- a/Documentation/git-config.adoc\n+++ b/Documentation/git-config.adoc\n@@ -476,7 +476,7 @@ GIT_CONFIG_SYSTEM::\n GIT_CONFIG_NOSYSTEM::\n \tWhether to skip reading settings from the system-wide\n \t$(prefix)/etc/gitconfig file. See linkgit:git[1] for details.\n-\n++\n See also <<FILES>>.\n \n GIT_CONFIG_COUNT::\n-- \ngitgitgadget\n\n"},{"id":"544930","messageId":"b48fe9f7abe794864ac4470c2620048c2e5e6b53.1780927027.git.gitgitgadget@gmail.com","threadId":"65770","inReplyTo":"pull.2139.git.1780927027.gitgitgadget@gmail.com","subject":"[PATCH 2/3] config: add GIT_CONFIG_INCLUDES","fromName":"Derrick Stolee via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-06-08T13:57:05Z","receivedAt":"2026-06-08T13:57:11Z","isPatch":true,"body":"From: Derrick Stolee <stolee@gmail.com>\n\nThe config keys 'include.path' and 'includeIf.*' allow users to specify\nconfig stored in a location outside of the typical list of config files\n(system, global, local, etc.). For example, users who accept the risk\ncan specify helpful aliases via a file checked into the repo by pointing\n'include.path' to the position of that file in the working directory.\nThis is dangerous, but people do it.\n\nWhat becomes tricky is that this modifies all Git behavior, including\noperations that are intended to be limited in activity or sandboxed in\nsome way. These include directives can provide surprising changes to\nbehavior, especially when expecting a specific list of allowed file\naccesses. This could lead to failed builds, for instance.\n\nTo allow for these user-desired features when they are running commands,\nadd a new GIT_CONFIG_INCLUDES environment variable that disables these\nredirections of config when set to zero. This variable can be set by\nautomation, such as build tooling, to avoid these strange behaviors.\nThis could be considered a recommended option for tools executing Git\ncommands, the same as GIT_ADVICE=0.\n\nSigned-off-by: Derrick Stolee <stolee@gmail.com>\n---\n Documentation/git-config.adoc |  5 +++++\n config.c                      |  7 ++++++-\n environment.h                 |  6 ++++++\n t/t1305-config-include.sh     | 31 +++++++++++++++++++++++++++++++\n 4 files changed, 48 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-config.adoc b/Documentation/git-config.adoc\nindex 044d776613..c9b5159501 100644\n--- a/Documentation/git-config.adoc\n+++ b/Documentation/git-config.adoc\n@@ -502,6 +502,11 @@ GIT_CONFIG::\n \thistorical compatibility; there is generally no reason to use it\n \tinstead of the `--file` option.\n \n+GIT_CONFIG_INCLUDES::\n+\tIf GIT_CONFIG_INCLUDES is set to 0, then Git will not follow\n+\t`include.path` or `includeIf.*.path` directives when reading\n+\tconfiguration files.\n+\n [[EXAMPLES]]\n EXAMPLES\n --------\ndiff --git a/config.c b/config.c\nindex a1b92fe083..85edd05672 100644\n--- a/config.c\n+++ b/config.c\n@@ -1595,9 +1595,14 @@ int config_with_options(config_fn_t fn, void *data,\n \t\t\tconst struct config_options *opts)\n {\n \tstruct config_include_data inc = CONFIG_INCLUDE_INIT;\n+\tint respect_includes = opts->respect_includes;\n \tint ret;\n \n-\tif (opts->respect_includes) {\n+\tif (respect_includes &&\n+\t    !git_env_bool(CONFIG_INCLUDES_ENVIRONMENT, 1))\n+\t\trespect_includes = 0;\n+\n+\tif (respect_includes) {\n \t\tinc.fn = fn;\n \t\tinc.data = data;\n \t\tinc.opts = opts;\ndiff --git a/environment.h b/environment.h\nindex 9eb97b3869..2c57ae2533 100644\n--- a/environment.h\n+++ b/environment.h\n@@ -52,6 +52,12 @@\n  */\n #define GIT_ADVICE_ENVIRONMENT \"GIT_ADVICE\"\n \n+/*\n+ * Environment variable used to prevent following include.path or includeIf.*\n+ * config directives.\n+ */\n+#define CONFIG_INCLUDES_ENVIRONMENT \"GIT_CONFIG_INCLUDES\"\n+\n /*\n  * Environment variable used in handshaking the wire protocol.\n  * Contains a colon ':' separated list of keys with optional values\ndiff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh\nindex f3892578e4..270e4b89ab 100755\n--- a/t/t1305-config-include.sh\n+++ b/t/t1305-config-include.sh\n@@ -396,4 +396,35 @@ test_expect_success 'onbranch without repository but explicit nonexistent Git di\n \ttest_must_fail nongit git --git-dir=nonexistent config get foo.bar\n '\n \n+test_expect_success 'GIT_CONFIG_INCLUDES=0 disables include.path and includeIf' '\n+\ttest_when_finished \"rm -rf repo\" &&\n+\tgit init repo &&\n+\t(\n+\t\tcd repo &&\n+\t\tgit config set include.path config.inc &&\n+\t\tgit config set \"includeIf.gitdir:*.path\" config2.inc &&\n+\t\tgit config set -f .git/config.inc foo.bar from-include &&\n+\t\tgit config set -f .git/config2.inc foo.baz from-includeif &&\n+\t\tgit config get foo.bar &&\n+\t\tgit config get foo.baz &&\n+\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git config get foo.bar &&\n+\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git config get foo.baz &&\n+\t\tgit config get --includes foo.bar &&\n+\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git config get --includes foo.bar\n+\t)\n+'\n+\n+test_expect_success 'GIT_CONFIG_INCLUDES=0 blocks included alias override' '\n+\ttest_when_finished \"rm -rf repo\" &&\n+\tgit init repo &&\n+\t(\n+\t\tcd repo &&\n+\t\tgit config set alias.test false &&\n+\t\tgit config set include.path config.inc &&\n+\t\tgit config set -f .git/config.inc alias.test status &&\n+\t\tgit test &&\n+\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git test\n+\t)\n+'\n+\n test_done\n-- \ngitgitgadget\n\n"},{"id":"544929","messageId":"1b4ae3cc0b9bc18f0b001587e93ce83cf3dfa819.1780927027.git.gitgitgadget@gmail.com","threadId":"65770","inReplyTo":"pull.2139.git.1780927027.gitgitgadget@gmail.com","subject":"[PATCH 3/3] git: add --no-includes top-level option","fromName":"Derrick Stolee via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2026-06-08T13:57:06Z","receivedAt":"2026-06-08T13:57:12Z","isPatch":true,"body":"From: Derrick Stolee <stolee@gmail.com>\n\nThe previous change added a GIT_CONFIG_INCLUDES=0 override in the\nenvironment, similar to GIT_ADVICE=0. Follow the same model as\n--no-advice to add a --no-includes option to the top-level Git options.\n\nSigned-off-by: Derrick Stolee <stolee@gmail.com>\n---\n Documentation/git.adoc    | 6 +++++-\n git.c                     | 6 +++++-\n t/t1305-config-include.sh | 8 ++++++--\n 3 files changed, 16 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git.adoc b/Documentation/git.adoc\nindex 8a5cdd3b3d..f220427930 100644\n--- a/Documentation/git.adoc\n+++ b/Documentation/git.adoc\n@@ -12,7 +12,7 @@ SYNOPSIS\n 'git' [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]\n     [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n     [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]\n-    [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]\n+    [--no-optional-locks] [--no-advice] [--no-includes] [--bare] [--git-dir=<path>]\n     [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]\n     <command> [<args>]\n \n@@ -194,6 +194,10 @@ If you just want to run git as if it was started in `<path>` then use\n --no-advice::\n \tDisable all advice hints from being printed.\n \n+--no-includes::\n+\tDisable all `include.path` and `includeIf.*` config directives.\n+\tSee linkgit:git-config[1] for more information.\n+\n --literal-pathspecs::\n \tTreat pathspecs literally (i.e. no globbing, no pathspec magic).\n \tThis is equivalent to setting the `GIT_LITERAL_PATHSPECS` environment\ndiff --git a/git.c b/git.c\nindex 36f08891ef..52cfbf0e23 100644\n--- a/git.c\n+++ b/git.c\n@@ -40,7 +40,7 @@ const char git_usage_string[] =\n \tN_(\"git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]\\n\"\n \t   \"           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\\n\"\n \t   \"           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]\\n\"\n-\t   \"           [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]\\n\"\n+\t   \"           [--no-optional-locks] [--no-advice] [--no-includes] [--bare] [--git-dir=<path>]\\n\"\n \t   \"           [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]\\n\"\n \t   \"           <command> [<args>]\");\n \n@@ -354,6 +354,10 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)\n \t\t\tsetenv(GIT_ADVICE_ENVIRONMENT, \"0\", 1);\n \t\t\tif (envchanged)\n \t\t\t\t*envchanged = 1;\n+\t\t} else if (!strcmp(cmd, \"--no-includes\")) {\n+\t\t\tsetenv(CONFIG_INCLUDES_ENVIRONMENT, \"0\", 1);\n+\t\t\tif (envchanged)\n+\t\t\t\t*envchanged = 1;\n \t\t} else {\n \t\t\tfprintf(stderr, _(\"unknown option: %s\\n\"), cmd);\n \t\t\tusage(git_usage_string);\ndiff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh\nindex 270e4b89ab..b636e5ae7b 100755\n--- a/t/t1305-config-include.sh\n+++ b/t/t1305-config-include.sh\n@@ -409,8 +409,11 @@ test_expect_success 'GIT_CONFIG_INCLUDES=0 disables include.path and includeIf'\n \t\tgit config get foo.baz &&\n \t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git config get foo.bar &&\n \t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git config get foo.baz &&\n+\t\ttest_must_fail git --no-includes config get foo.bar &&\n+\t\ttest_must_fail git --no-includes config get foo.baz &&\n \t\tgit config get --includes foo.bar &&\n-\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git config get --includes foo.bar\n+\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git config get --includes foo.bar &&\n+\t\ttest_must_fail git --no-includes config get --includes foo.bar\n \t)\n '\n \n@@ -423,7 +426,8 @@ test_expect_success 'GIT_CONFIG_INCLUDES=0 blocks included alias override' '\n \t\tgit config set include.path config.inc &&\n \t\tgit config set -f .git/config.inc alias.test status &&\n \t\tgit test &&\n-\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git test\n+\t\ttest_must_fail env GIT_CONFIG_INCLUDES=0 git test &&\n+\t\ttest_must_fail git --no-includes test\n \t)\n '\n \n-- \ngitgitgadget\n"},{"id":"544932","messageId":"aibTAOrcSvTOtv78@pks.im","threadId":"65770","inReplyTo":"b48fe9f7abe794864ac4470c2620048c2e5e6b53.1780927027.git.gitgitgadget@gmail.com","subject":"Re: [PATCH 2/3] config: add GIT_CONFIG_INCLUDES","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-06-08T14:34:40Z","receivedAt":"2026-06-08T14:34:46Z","isPatch":true,"body":"On Mon, Jun 08, 2026 at 01:57:05PM +0000, Derrick Stolee via GitGitGadget wrote:\n> From: Derrick Stolee <stolee@gmail.com>\n> \n> The config keys 'include.path' and 'includeIf.*' allow users to specify\n> config stored in a location outside of the typical list of config files\n> (system, global, local, etc.). For example, users who accept the risk\n> can specify helpful aliases via a file checked into the repo by pointing\n> 'include.path' to the position of that file in the working directory.\n> This is dangerous, but people do it.\n\nHuh, I never even considered this use case. But of course, this is\npossible, even though it's quite scary.\n\n> What becomes tricky is that this modifies all Git behavior, including\n> operations that are intended to be limited in activity or sandboxed in\n> some way. These include directives can provide surprising changes to\n> behavior, especially when expecting a specific list of allowed file\n> accesses. This could lead to failed builds, for instance.\n> \n> To allow for these user-desired features when they are running commands,\n> add a new GIT_CONFIG_INCLUDES environment variable that disables these\n> redirections of config when set to zero. This variable can be set by\n> automation, such as build tooling, to avoid these strange behaviors.\n> This could be considered a recommended option for tools executing Git\n> commands, the same as GIT_ADVICE=0.\n\nI don't know about this part though. I could see use cases where the\ntools _should_ read the project-relative configuration. It might also be\nthe case that the user may want to evaluate some includes, but not all\nof them.\n\nThat raises the question whether we can introduce the configuration in a\nway that it allows a bit more flexibility than just \"yes\"/\"no\", like for\nexample an allow-list of locations that should be evaluated. But maybe\nI'm overthinking this.\n\nPatrick\n"},{"id":"544965","messageId":"dd971b9e-2c13-4521-b991-b9bee1c5bf5b@gmail.com","threadId":"65770","inReplyTo":"aibTAOrcSvTOtv78@pks.im","subject":"Re: [PATCH 2/3] config: add GIT_CONFIG_INCLUDES","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-06-08T19:38:55Z","receivedAt":"2026-06-08T19:38:57Z","isPatch":true,"body":"On 6/8/2026 10:34 AM, Patrick Steinhardt wrote:\n> On Mon, Jun 08, 2026 at 01:57:05PM +0000, Derrick Stolee via GitGitGadget wrote:\n>> From: Derrick Stolee <stolee@gmail.com>\n>>\n>> The config keys 'include.path' and 'includeIf.*' allow users to specify\n>> config stored in a location outside of the typical list of config files\n>> (system, global, local, etc.). For example, users who accept the risk\n>> can specify helpful aliases via a file checked into the repo by pointing\n>> 'include.path' to the position of that file in the working directory.\n>> This is dangerous, but people do it.\n> \n> Huh, I never even considered this use case. But of course, this is\n> possible, even though it's quite scary.\n> \n>> What becomes tricky is that this modifies all Git behavior, including\n>> operations that are intended to be limited in activity or sandboxed in\n>> some way. These include directives can provide surprising changes to\n>> behavior, especially when expecting a specific list of allowed file\n>> accesses. This could lead to failed builds, for instance.\n>>\n>> To allow for these user-desired features when they are running commands,\n>> add a new GIT_CONFIG_INCLUDES environment variable that disables these\n>> redirections of config when set to zero. This variable can be set by\n>> automation, such as build tooling, to avoid these strange behaviors.\n>> This could be considered a recommended option for tools executing Git\n>> commands, the same as GIT_ADVICE=0.\n> \n> I don't know about this part though. I could see use cases where the\n> tools _should_ read the project-relative configuration. It might also be\n> the case that the user may want to evaluate some includes, but not all\n> of them.\n\nTrue. I'm not confident that we should recommend this environment in all\ncases.\n\n> That raises the question whether we can introduce the configuration in a\n> way that it allows a bit more flexibility than just \"yes\"/\"no\", like for\n> example an allow-list of locations that should be evaluated. But maybe\n> I'm overthinking this.\nI see. So we can say \"avoid including into the repository worktree\" but\nthat will probably be incomplete.\n\nThere is room for nuance in future expansions, if we can find a creative\nway to handle that nuance. For now, I think I would still want an ability\nto turn the entire feature off, at least for certain tools that care.\n\nThanks,\n-Stolee\n"},{"id":"544976","messageId":"20260608225149.GB340696@coredump.intra.peff.net","threadId":"65770","inReplyTo":"pull.2139.git.1780927027.gitgitgadget@gmail.com","subject":"Re: [PATCH 0/3] config: allow disabling config includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-08T22:51:49Z","receivedAt":"2026-06-08T22:51:50Z","isPatch":true,"body":"On Mon, Jun 08, 2026 at 01:57:03PM +0000, Derrick Stolee via GitGitGadget wrote:\n\n> This series introduces a new way to ignore config include directives via two\n> mechanisms:\n> \n>  * GIT_CONFIG_INCLUDES=0 in the environment.\n>  * git --no-includes ... in the command line.\n> \n> My motivation is from a tricky situation where users want to do the risky\n> thing and include a repo-tracked file for sharing aliases and other\n> recommended config. They are then struggling in a later build step that is\n> running Git commands (under a tool we don't control and can't change) that\n> then cause filesystem accesses outside of the build system's sandbox.\n\nI'm not opposed to global control of includes, but this is just one way\nin which config can escape the sandbox. They can always point to files\n(e.g., core.attributesFile) or even commands that totally leave the\nsandbox (e.g., ext diff or textconv commands). Fundamentally git config\nis equivalent to arbitrary code execution, so pointing an include at a\nrepo-tracked file carries the risk of confusion both malicious and\naccidental.\n\nSo I dunno. From the described motivation, this feels like a band-aid\nthat fixes only one narrow instance of a greater problem.\n\nThe notion of enabling/disabling includes per-command is itself a\nflexible building block. So it's possible that it has other uses in\ngeneral. But it's also a fairly broad hammer that covers more than your\nuse case. If you're planning to use \"git --no-includes\" in some script,\nthen it breaks the config of anybody who uses includes in their\nuser-level ~/.gitconfig file.\n\nSo you may need some more directed limiting.\n\n> One thing I do worry about is whether or not this would cause a significant\n> break in behavior, or if this is a relatively safe thing to allow.\n\nYeah. Consider something like:\n\n  $ cat ~/.gitconfig\n  [user]\n  name = My Name\n  email = me@personal.example.com\n  [includeIf \"gitdir:/path/to/work/stuff\"]\n  path = .gitconfig-work\n\n  $ cat ~/.gitconfig-work\n  [user]\n  email = me@work.example.com\n\nUsing \"git --no-include\" will silently use the wrong user.email value.\nThat's OK if the user is asking for it, but if you are planning to\nsprinkle \"--no-include\" inside scripts, that's likely to cause\nconfusion.\n\n-Peff\n"},{"id":"545011","messageId":"aietZKn2-nUKpeQz@pks.im","threadId":"65770","inReplyTo":"dd971b9e-2c13-4521-b991-b9bee1c5bf5b@gmail.com","subject":"Re: [PATCH 2/3] config: add GIT_CONFIG_INCLUDES","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-06-09T06:06:28Z","receivedAt":"2026-06-09T06:06:34Z","isPatch":true,"body":"On Mon, Jun 08, 2026 at 03:38:55PM -0400, Derrick Stolee wrote:\n> On 6/8/2026 10:34 AM, Patrick Steinhardt wrote:\n> > On Mon, Jun 08, 2026 at 01:57:05PM +0000, Derrick Stolee via GitGitGadget wrote:\n> > That raises the question whether we can introduce the configuration in a\n> > way that it allows a bit more flexibility than just \"yes\"/\"no\", like for\n> > example an allow-list of locations that should be evaluated. But maybe\n> > I'm overthinking this.\n> I see. So we can say \"avoid including into the repository worktree\" but\n> that will probably be incomplete.\n> \n> There is room for nuance in future expansions, if we can find a creative\n> way to handle that nuance. For now, I think I would still want an ability\n> to turn the entire feature off, at least for certain tools that care.\n\nYup, that's fine with me. Thanks!\n\nPatrick\n"},{"id":"545066","messageId":"4d7834c0-d8ab-4dcd-8a7f-ed62c30cbe43@gmail.com","threadId":"65770","inReplyTo":"20260608225149.GB340696@coredump.intra.peff.net","subject":"Re: [PATCH 0/3] config: allow disabling config includes","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-06-09T12:59:22Z","receivedAt":"2026-06-09T12:59:27Z","isPatch":true,"body":"On 6/8/2026 6:51 PM, Jeff King wrote:\n> On Mon, Jun 08, 2026 at 01:57:03PM +0000, Derrick Stolee via GitGitGadget wrote:\n> \n>> This series introduces a new way to ignore config include directives via two\n>> mechanisms:\n>>\n>>  * GIT_CONFIG_INCLUDES=0 in the environment.\n>>  * git --no-includes ... in the command line.\n>>\n>> My motivation is from a tricky situation where users want to do the risky\n>> thing and include a repo-tracked file for sharing aliases and other\n>> recommended config. They are then struggling in a later build step that is\n>> running Git commands (under a tool we don't control and can't change) that\n>> then cause filesystem accesses outside of the build system's sandbox.\n> \n> I'm not opposed to global control of includes, but this is just one way\n> in which config can escape the sandbox. They can always point to files\n> (e.g., core.attributesFile) or even commands that totally leave the\n> sandbox (e.g., ext diff or textconv commands). Fundamentally git config\n> is equivalent to arbitrary code execution, so pointing an include at a\n> repo-tracked file carries the risk of confusion both malicious and\n> accidental.\n> \n> So I dunno. From the described motivation, this feels like a band-aid\n> that fixes only one narrow instance of a greater problem.\n> \n> The notion of enabling/disabling includes per-command is itself a\n> flexible building block. So it's possible that it has other uses in\n> general. But it's also a fairly broad hammer that covers more than your\n> use case. If you're planning to use \"git --no-includes\" in some script,\n> then it breaks the config of anybody who uses includes in their\n> user-level ~/.gitconfig file.\n> \n> So you may need some more directed limiting.\n\nAre you suggesting some kind of internal sandbox to limit Git from\naccessing repository paths from config includes and other config-set keys?\nThat would be a more complete solution, but I'm not sure how we could plug\nall of those holes at once. I'll think on it, though.\n\n>> One thing I do worry about is whether or not this would cause a significant\n>> break in behavior, or if this is a relatively safe thing to allow.\n> \n> Yeah. Consider something like:\n> \n>   $ cat ~/.gitconfig\n>   [user]\n>   name = My Name\n>   email = me@personal.example.com\n>   [includeIf \"gitdir:/path/to/work/stuff\"]\n>   path = .gitconfig-work\n> \n>   $ cat ~/.gitconfig-work\n>   [user]\n>   email = me@work.example.com\n> \n> Using \"git --no-include\" will silently use the wrong user.email value.\n> That's OK if the user is asking for it, but if you are planning to\n> sprinkle \"--no-include\" inside scripts, that's likely to cause\n> confusion.\n\nThis is exactly the kind of case I was worried about. This specific case\nonly impacts write operations, but some tools do those things. And this\nemail case is a common one that users do in their global config to isolate\npersonal and professional identities.\n\nI'm trying to think if there's a place where we'd have some config that is\ncritical to the repo functioning not in its local config (like the repo\nformat version or extensions). Perhaps borrowing from your work/personal\nexample, a user could use a different credential helper for work than they\nuse for personal repositories.\n\nPerhaps we need to be very careful to warn users of this option or\nenvironment variable that behavior can change from typical use.\n\nOr: are we venturing into territory where we don't even want to create a\nnew foot-gun? If there were another way to solve the situation that I'm\nfacing without these risks, then I'd be open to it. Any ideas?\n\nThanks,\n-Stolee\n"},{"id":"545256","messageId":"20260611083943.GJ2191159@coredump.intra.peff.net","threadId":"65770","inReplyTo":"4d7834c0-d8ab-4dcd-8a7f-ed62c30cbe43@gmail.com","subject":"Re: [PATCH 0/3] config: allow disabling config includes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-11T08:39:43Z","receivedAt":"2026-06-11T08:39:44Z","isPatch":true,"body":"On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:\n\n> > So I dunno. From the described motivation, this feels like a band-aid\n> > that fixes only one narrow instance of a greater problem.\n> > \n> > The notion of enabling/disabling includes per-command is itself a\n> > flexible building block. So it's possible that it has other uses in\n> > general. But it's also a fairly broad hammer that covers more than your\n> > use case. If you're planning to use \"git --no-includes\" in some script,\n> > then it breaks the config of anybody who uses includes in their\n> > user-level ~/.gitconfig file.\n> > \n> > So you may need some more directed limiting.\n> \n> Are you suggesting some kind of internal sandbox to limit Git from\n> accessing repository paths from config includes and other config-set keys?\n> That would be a more complete solution, but I'm not sure how we could plug\n> all of those holes at once. I'll think on it, though.\n\nI don't know that I'm really suggesting anything, but more just thinking\nout loud. My concern would be that we plug one such hole, and then later\nfind we need more. And then we are stuck with the solution for plugging\nthat hole, even if it may later become redundant.\n\nI'm not sure I entirely understand the problematic case, though. The\nuser points to in-repo config (which we already tell people is a bad\nidea), and then that config breaks for some reason? Because the include\nis relative and git is run from another directory?\n\nIf you are going to make such an include, I'd hope you'd at least do it\nfrom .git/config, which should reliably resolve relative paths based on\nthe source include file, not the current working directory.\n\n> This is exactly the kind of case I was worried about. This specific case\n> only impacts write operations, but some tools do those things. And this\n> email case is a common one that users do in their global config to isolate\n> personal and professional identities.\n\nYeah, I picked it because I suspect it is a very common use of includes.\nBut really it is up to users to do whatever they want with includes, and\nthey'd probably expect them to always work.\n\n> I'm trying to think if there's a place where we'd have some config that is\n> critical to the repo functioning not in its local config (like the repo\n> format version or extensions). Perhaps borrowing from your work/personal\n> example, a user could use a different credential helper for work than they\n> use for personal repositories.\n\nIt depends what you mean by critical, I suppose. If I happen to prefer\nshoving all of my diff.*.textconv commands into ~/.gitconfig-diff, then\nincluding it with include.path=.gitconfig-diff in ~/.gitconfig, I'd\nexpect it to just work everywhere. But disabling includes would violate\nthat assumption. Probably not _critical_, but it could be annoying and\nsurprising.\n\n> Or: are we venturing into territory where we don't even want to create a\n> new foot-gun? If there were another way to solve the situation that I'm\n> facing without these risks, then I'd be open to it. Any ideas?\n\nYeah, the more I think on it, the more it seems like a foot-gun. Like I\nsaid, I'm not sure I entirely understand the use-case. If you could\nflesh out an example, that might help.\n\n-Peff\n"},{"id":"545269","messageId":"539713c4-b291-42e6-8541-a16a454518f5@gmail.com","threadId":"65770","inReplyTo":"20260611083943.GJ2191159@coredump.intra.peff.net","subject":"Re: [PATCH 0/3] config: allow disabling config includes","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-06-11T13:08:45Z","receivedAt":"2026-06-11T13:08:47Z","isPatch":true,"body":"On 6/11/2026 4:39 AM, Jeff King wrote:\n> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:\n\n> I'm not sure I entirely understand the problematic case, though. The\n> user points to in-repo config (which we already tell people is a bad\n> idea), and then that config breaks for some reason? Because the include\n> is relative and git is run from another directory?\n\n>> Or: are we venturing into territory where we don't even want to create a\n>> new foot-gun? If there were another way to solve the situation that I'm\n>> facing without these risks, then I'd be open to it. Any ideas?\n> \n> Yeah, the more I think on it, the more it seems like a foot-gun. Like I\n> said, I'm not sure I entirely understand the use-case. If you could\n> flesh out an example, that might help.\nThe case I'm struggling with is that our build system has sandboxing\nrestrictions to make sure the build is deterministic based on a certain\nnumber of inputs. A tool we don't control is calling Git commands and\nthese users with included config are getting errors because the build\nis looking at files in the repo that are not registered as build inputs.\n\nFiles within $SRCROOT/.git/ are ignored as \"internal to Git\" but when\nthe users update their config to include other files, this error occurs.\n\nI'd much rather that this tool doesn't call Git at all, but I'm unable\nto make that change to a third-party tool. But this environment variable\nwould make it possible to disable this behavior. And I'd also rather\nthat these users don't use includes in this way, but they are using a\nchecked-in file to share aliases and other quality-of-life things when\na human uses Git, not \"critical\" settings.\n\nThis series is my attempt to see if we can find a solution that enables\nthis behavior, but maybe we've found enough concerns with the idea that\nwe can push back on the users to say \"stop doing that.\"\n\nThanks,\n-Stolee\n\n"},{"id":"545790","messageId":"xmqqzf0tuhfm.fsf@gitster.g","threadId":"65770","inReplyTo":"539713c4-b291-42e6-8541-a16a454518f5@gmail.com","subject":"Re: [PATCH 0/3] config: allow disabling config includes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-06-17T18:53:49Z","receivedAt":"2026-06-17T18:53:51Z","isPatch":true,"body":"Derrick Stolee <stolee@gmail.com> writes:\n\n> On 6/11/2026 4:39 AM, Jeff King wrote:\n>> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:\n>\n>> I'm not sure I entirely understand the problematic case, though. The\n>> user points to in-repo config (which we already tell people is a bad\n>> idea), and then that config breaks for some reason? Because the include\n>> is relative and git is run from another directory?\n>\n>>> Or: are we venturing into territory where we don't even want to create a\n>>> new foot-gun? If there were another way to solve the situation that I'm\n>>> facing without these risks, then I'd be open to it. Any ideas?\n>> \n>> Yeah, the more I think on it, the more it seems like a foot-gun. Like I\n>> said, I'm not sure I entirely understand the use-case. If you could\n>> flesh out an example, that might help.\n> The case I'm struggling with is that our build system has sandboxing\n> restrictions to make sure the build is deterministic based on a certain\n> number of inputs. A tool we don't control is calling Git commands and\n> these users with included config are getting errors because the build\n> is looking at files in the repo that are not registered as build inputs.\n>\n> Files within $SRCROOT/.git/ are ignored as \"internal to Git\" but when\n> the users update their config to include other files, this error occurs.\n>\n> I'd much rather that this tool doesn't call Git at all, but I'm unable\n> to make that change to a third-party tool. But this environment variable\n> would make it possible to disable this behavior. And I'd also rather\n> that these users don't use includes in this way, but they are using a\n> checked-in file to share aliases and other quality-of-life things when\n> a human uses Git, not \"critical\" settings.\n>\n> This series is my attempt to see if we can find a solution that enables\n> this behavior, but maybe we've found enough concerns with the idea that\n> we can push back on the users to say \"stop doing that.\"\n\nIt seems that the thread went dark after this message.  Should I\ntake silence as an agreement, and mark the topic as retracted?\n\nThanks for an interesting discussion.\n"},{"id":"545796","messageId":"e88c6e7d-1236-4595-9dea-26c33eab6432@gmail.com","threadId":"65770","inReplyTo":"xmqqzf0tuhfm.fsf@gitster.g","subject":"Re: [PATCH 0/3] config: allow disabling config includes","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2026-06-17T20:21:08Z","receivedAt":"2026-06-17T20:21:10Z","isPatch":true,"body":"On 6/17/2026 2:53 PM, Junio C Hamano wrote:\n> Derrick Stolee <stolee@gmail.com> writes:\n> \n>> On 6/11/2026 4:39 AM, Jeff King wrote:\n>>> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:\n>>\n>>> I'm not sure I entirely understand the problematic case, though. The\n>>> user points to in-repo config (which we already tell people is a bad\n>>> idea), and then that config breaks for some reason? Because the include\n>>> is relative and git is run from another directory?\n>>\n>>>> Or: are we venturing into territory where we don't even want to create a\n>>>> new foot-gun? If there were another way to solve the situation that I'm\n>>>> facing without these risks, then I'd be open to it. Any ideas?\n>>>\n>>> Yeah, the more I think on it, the more it seems like a foot-gun. Like I\n>>> said, I'm not sure I entirely understand the use-case. If you could\n>>> flesh out an example, that might help.\n>> The case I'm struggling with is that our build system has sandboxing\n>> restrictions to make sure the build is deterministic based on a certain\n>> number of inputs. A tool we don't control is calling Git commands and\n>> these users with included config are getting errors because the build\n>> is looking at files in the repo that are not registered as build inputs.\n>>\n>> Files within $SRCROOT/.git/ are ignored as \"internal to Git\" but when\n>> the users update their config to include other files, this error occurs.\n>>\n>> I'd much rather that this tool doesn't call Git at all, but I'm unable\n>> to make that change to a third-party tool. But this environment variable\n>> would make it possible to disable this behavior. And I'd also rather\n>> that these users don't use includes in this way, but they are using a\n>> checked-in file to share aliases and other quality-of-life things when\n>> a human uses Git, not \"critical\" settings.\n>>\n>> This series is my attempt to see if we can find a solution that enables\n>> this behavior, but maybe we've found enough concerns with the idea that\n>> we can push back on the users to say \"stop doing that.\"\n> \n> It seems that the thread went dark after this message.  Should I\n> take silence as an agreement, and mark the topic as retracted?\n> \n> Thanks for an interesting discussion.\n\nYes, consider this retracted. I saw you made that note in the What's\nCooking email so I thought it was understood.\n\nI believe that the risk is not worth the reward here.\n\nThanks,\n-Stolee\n"},{"id":"545797","messageId":"xmqqik7gvrvx.fsf@gitster.g","threadId":"65770","inReplyTo":"e88c6e7d-1236-4595-9dea-26c33eab6432@gmail.com","subject":"Re: [PATCH 0/3] config: allow disabling config includes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-06-17T20:22:42Z","receivedAt":"2026-06-17T20:22:44Z","isPatch":true,"body":"Derrick Stolee <stolee@gmail.com> writes:\n\n> On 6/17/2026 2:53 PM, Junio C Hamano wrote:\n>> Derrick Stolee <stolee@gmail.com> writes:\n>> \n>>> On 6/11/2026 4:39 AM, Jeff King wrote:\n>>>> On Tue, Jun 09, 2026 at 08:59:22AM -0400, Derrick Stolee wrote:\n>>>\n>>>> I'm not sure I entirely understand the problematic case, though. The\n>>>> user points to in-repo config (which we already tell people is a bad\n>>>> idea), and then that config breaks for some reason? Because the include\n>>>> is relative and git is run from another directory?\n>>>\n>>>>> Or: are we venturing into territory where we don't even want to create a\n>>>>> new foot-gun? If there were another way to solve the situation that I'm\n>>>>> facing without these risks, then I'd be open to it. Any ideas?\n>>>>\n>>>> Yeah, the more I think on it, the more it seems like a foot-gun. Like I\n>>>> said, I'm not sure I entirely understand the use-case. If you could\n>>>> flesh out an example, that might help.\n>>> The case I'm struggling with is that our build system has sandboxing\n>>> restrictions to make sure the build is deterministic based on a certain\n>>> number of inputs. A tool we don't control is calling Git commands and\n>>> these users with included config are getting errors because the build\n>>> is looking at files in the repo that are not registered as build inputs.\n>>>\n>>> Files within $SRCROOT/.git/ are ignored as \"internal to Git\" but when\n>>> the users update their config to include other files, this error occurs.\n>>>\n>>> I'd much rather that this tool doesn't call Git at all, but I'm unable\n>>> to make that change to a third-party tool. But this environment variable\n>>> would make it possible to disable this behavior. And I'd also rather\n>>> that these users don't use includes in this way, but they are using a\n>>> checked-in file to share aliases and other quality-of-life things when\n>>> a human uses Git, not \"critical\" settings.\n>>>\n>>> This series is my attempt to see if we can find a solution that enables\n>>> this behavior, but maybe we've found enough concerns with the idea that\n>>> we can push back on the users to say \"stop doing that.\"\n>> \n>> It seems that the thread went dark after this message.  Should I\n>> take silence as an agreement, and mark the topic as retracted?\n>> \n>> Thanks for an interesting discussion.\n>\n> Yes, consider this retracted. I saw you made that note in the What's\n> Cooking email so I thought it was understood.\n>\n> I believe that the risk is not worth the reward here.\n\nThanks.  Will drop.\n"}]}