Re: [BUG] fatal: transport 'file' not allowed during submodule add

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Randall,

rsbecker@nexbridge.com wrote:
> Junio C Hamano wrote:

>> This suspiciously sounds like what a1d4f67c (transport: make `protocol.file.allow`
>> be "user" by default, 2022-07-29) is doing deliberately.
>
> I have tried using 'git config --local protocol.file.allow always' and/or
> 'git config --local protocol.allow always' to get past this, without
> success.

Does `git config --global protocol.file.allow always` do the trick?

>>                                                           Taylor, does this look like a
>> corner case the 2.30.6 updates forgot to consider?

I think it's the intended effect (preventing file:// submodules), but
I wonder if this hints that we'd want that protection to be more
targeted.  A file:// submodule (as opposed to a bare path without URL
scheme) wouldn't trigger the "git clone --local" behavior that that
commit mentions wanting to protect against, so at first glance it
would appear to be no more or less dangerous than cloning from a
remote repository.

One thing I'd be curious about is whether --local happening
automatically is actually worth it nowadays.  "git worktree" does a
better job of sharing with an existing local repository, since the
sharing continues even after the worktree has been created, after any
"git gc" operations, and so on.  Meanwhile, the distinction between
file:// and bare paths is subtle enough that I regularly encounter
people not being aware of it (for example when wanting a way to test
protocol code locally and not understanding why a bare-path clone
doesn't do that).  Would it be more in the spirit of secure defaults
to require --local when someone wants to request the hardlinking trick
of local clone?

Thanks,
Jonathan