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:
signature.asc
Description: PGP signature
