# [BUG] protocol.file.allow=always not honored when --local 3 messages from 2025-10-17 to 2025-10-21. Participants: fence.borrowing375@passmail.net, Jeff King. Thread: https://gitlist.dev/t/64342 ## fence.borrowing375@passmail.net, 2025-10-17 02:19 Subject: [BUG] protocol.file.allow=always not honored when --local Message-ID: <176066758616.6.12811000416591629223.957743298@passmail.net> URL: https://gitlist.dev/e/176066758616.6.12811000416591629223.957743298%40passmail.net ``` Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue) Created an empty directory, then initialized git: `mkdir ~/test && cd ~/test && git init` Ensured file:// transport protocol is default/unset value (file:// is disabled by default): `git config --list | grep protocol` # no output Enabled file:// transport for local repository: `git config --local protocol.file.allow always` Then, attempted to add a git submodule: `git submodule add /path/to/module/.git` What did you expect to happen? (Expected behavior) Successful clone: ˋˋˋ Cloning into '/home/username/test/module'... done. ˋˋˋ What happened instead? (Actual behavior) Failed clone: ˋˋˋ Cloning into '/home/username/test/module'... fatal: transport 'file' not allowed fatal: clone of '/path/to/module/.git' into submodule path '/home/head/data/infra/src/test/git' failed ˋˋˋ What's different between what you expected and what actually happened? The default behavior of disabling the file:// protocol should have been overridden by the config, but was not. In contrast, it gets enabled as expected when setting the config user-wide: `git config --global protocol.file.allow always` I do not want to enable file:// by default due to security implications. I only want to enable it for specific repositories but cannot do so as this setting is not honored when --local. Anything else you want to add: A similar error message shows when attempting to update an existing submodule with only the --local config set. This bug is also present in git version 2.39.5. [System Info] git version: git version 2.51.1.472.g4253630c6f cpu: x86_64 built from commit: 4253630c6f07a4bdcc9aa62a50e26a4d466219d1 sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh rust: disabled libcurl: 7.88.1 OpenSSL: OpenSSL 3.0.17 1 Jul 2025 zlib: 1.2.13 SHA-1: SHA1_DC SHA-256: SHA256_BLK default-ref-format: files default-hash: sha1 compiler info: gnuc: 12.2 libc info: glibc: 2.36 $SHELL (typically, interactive shell): /bin/bash ``` ## Jeff King, 2025-10-17 07:15 Subject: Re: [BUG] protocol.file.allow=always not honored when --local Message-ID: <20251017071532.GA4073661@coredump.intra.peff.net> URL: https://gitlist.dev/e/20251017071532.GA4073661%40coredump.intra.peff.net In-Reply-To: <176066758616.6.12811000416591629223.957743298@passmail.net> ``` On Fri, Oct 17, 2025 at 02:19:38AM +0000, fence.borrowing375@passmail.net wrote: > Created an empty directory, then initialized git: > `mkdir ~/test && cd ~/test && git init` > > Ensured file:// transport protocol is default/unset value (file:// is > disabled by default): > `git config --list | grep protocol` > # no output > > Enabled file:// transport for local repository: > `git config --local protocol.file.allow always` > > Then, attempted to add a git submodule: > `git submodule add /path/to/module/.git` I don't think this will work as you expect, because of the use of "git config --local". When we run git-clone under the hood to clone the new submodule, it is a new repository, and does not look at the config of the containing repository at all[1]. As you noted, setting it in the user-level "--global" config file would work. You can also override the config via the environment like: git -c protocol.file.allow=always submodule add ... though note that anybody cloning will need to do the same thing (and of course have the submodule available at the exact same local path!). -Peff [1] There have been discussions in the past on whether submodules should receive some config from the superproject repository. But there are a lot of complications, as it is the right thing for some config keys but not for some others. I doubt we will change the behavior anytime soon. ``` ## fence.borrowing375@passmail.net, 2025-10-21 14:41 Subject: Re: [BUG] protocol.file.allow=always not honored when --local Message-ID: <176105772451.7.13453872556381855079.964553330@passmail.net> URL: https://gitlist.dev/e/176105772451.7.13453872556381855079.964553330%40passmail.net In-Reply-To: <20251017071532.GA4073661@coredump.intra.peff.net> ``` (I apologize for resending this, the first time I forgot to CC the mailing list.) The -c flag works for my use case, but this raises a couple questions: - If submodules were ever to use the local config, would it be the right thing to honor the protocol.allow and protocol..allow keys? - Manpage GIT-SUBMODULE(1), under the add, init, and update subcommands, notes that the local (superproject repository) config may be updated when running these commands. In addition, the local config is used for certain purposes, such as determining the default remote of a new submodule. Readers know the local config is used in some way. However, the manpage does not appear to state anywhere that, in general, the local config is currently ignored. I found this confusing. Is this a documentation bug? On Fri, 2025-10-17 at 03:15 -0400, Jeff King wrote: > On Fri, Oct 17, 2025 at 02:19:38AM +0000, > fence.borrowing375@passmail.net wrote: > > > Created an empty directory, then initialized git: > > `mkdir ~/test && cd ~/test && git init` > > > > Ensured file:// transport protocol is default/unset value (file:// > > is > > disabled by default): > > `git config --list | grep protocol` > > # no output > > > > Enabled file:// transport for local repository: > > `git config --local protocol.file.allow always` > > > > Then, attempted to add a git submodule: > > `git submodule add /path/to/module/.git` > > I don't think this will work as you expect, because of the use of > "git > config --local". When we run git-clone under the hood to clone the > new > submodule, it is a new repository, and does not look at the config of > the containing repository at all[1]. > > As you noted, setting it in the user-level "--global" config file > would > work. You can also override the config via the environment like: > >   git -c protocol.file.allow=always submodule add ... > > though note that anybody cloning will need to do the same thing (and > of > course have the submodule available at the exact same local path!). > > -Peff > > [1] There have been discussions in the past on whether submodules > should >     receive some config from the superproject repository. But there > are >     a lot of complications, as it is the right thing for some config >     keys but not for some others. I doubt we will change the behavior >     anytime soon. > ```