[BUG] protocol.file.allow=always not honored when --local

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

On Fri, Oct 17, 2025 at 02:19:38AM +0000, fence.borrowing375@passmail.net wrote:

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.

(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.<name>.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: