Re: Would it be possible to add an option to disable validating submodule paths?

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

On 2025-01-07 at 22:00:58, Vadim Zeitlin wrote:
>  In e8d0608944 (submodule: require the submodule path to contain
> directories only, 2024-03-26) a check that submodule paths don't contain
> symlinks was added to Git. I understand that this check is generally useful
> and helpful, but I'd really like to have some way of disabling it for some
> trusted repositories and _allow_ some of their submodules to be symlinks
> (see below for the rationale).
> 
>  Unfortunately, there doesn't seem to be any way to do it currently and I'd
> like to ask if I might, perhaps, be missing such a way or, if I don't,
> whether a patch adding an option to do it could be accepted?
> 
>  As to why I'd like to disable it, it's the usual story: this change broke
> my workflow (https://xkcd.com/1172/). I have a relatively big Git
> repository that I use as a submodule in many of the projects I'm working on
> and I used to just symlink the corresponding submodule directory to one,
> primary copy of this repository present on my system, instead of really
> initializing the submodule. This saved me many gigabytes of disk space and
> is also much faster than reinitializing the submodule every time I start a
> new project or, more frequently, create a new worktree for the existing
> one. And this worked just fine for many years but doesn't work any longer
> as any operation on the repository, even just "git status", now gives
> 
> error: expected submodule path 'submodule/path' not to be a symbolic link
> 
> as soon as a symlink is detected. Under Linux I can use mount binds
> instead, but this is much less convenient for many reasons and I'd really
> prefer to just keep using symlinks. Would it be possible to (optionally)
> allow using them again?

Since this is a defense-in-depth change and it seems to have broken a
reasonable workflow, I think adding a config option for this would be
reasonable.  We've recently had some discussions on trying to limit the
defense-in-depth measures we implement on the security list in the
interests of allowing better discussion and feedback on the main list
and avoiding regressions in people's workflows, and I think your email
lends support to that approach.

I'm not presently planning to add such an option, but it shouldn't be
too hard to add a global variable for that (or maybe something under
struct repository) that's updated when parsing config, and then check it
in `validate_submodule_path`.  We'd need docs for that option as well,
but that would probably be it if someone wanted to do so.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]