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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jan 7, 2025, 23:09 UTC
Message-ID: <Z320RGb0tqNyvvxt@tapette.crustytoothpaste.net>
In-Reply-To: <Mahogany-0.68.0-2854301-20250107-230058.01@dark.tt-solutions.com>

On 2025-01-07 at 22:00:58, Vadim Zeitlin wrote:

Show 28 quoted lines

>  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