{"thread":{"id":"66051","subject":"submodule path with symlinks","startedAt":"2026-07-22T18:20:37Z","lastAt":"2026-07-22T18:20:37Z","messageCount":1,"participants":["Kyle Marek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"548792","messageId":"cb2bf72a-9bd0-48a7-9e51-2d67f0a9cac4@gmail.com","threadId":"66051","inReplyTo":null,"subject":"submodule path with symlinks","fromName":"Kyle Marek","fromEmail":"psppsn96@gmail.com","sentAt":"2026-07-22T18:20:34Z","receivedAt":"2026-07-22T18:20:37Z","isPatch":false,"body":"Hello,\n\nI've just hit this change in behavior introduced ~2 years ago, where \nsubmodule paths are no longer allowed to contain symlinks [1].\n\nThis change has broken a practice that I have used repeatedly over the \nyears, where several worktrees share the same copy of their submodules. \nIt has been very useful for project organization, but no longer works on \nupdated systems for \"security\" reasons. Please, I understand the risks \nassociated with symlinks, I do not want to be \"protected from myself\", \nand I do not want to re-architect affected projects.\n\nI see there is even a TODO comment about exactly this issue [2]:\n\n > TODO: allow exempting it via `safe.submodule.path` or something\n\nI'm surprised to see that this change went through without an \naccompanying commit to allowing exceptions or allowing the user accept \nthe risks associated with symlinks.\n\nIs there interest in implementing the TODO? Will you accept a patch for \nthis?\n\nThank you,\nKyle Marek\n\n[1]: https://git.kernel.org/pub/scm/git/git.git/commit/?id=e8d0608944486019ea0e1ed2ed29776811a565c2\n\n[2]: https://git.kernel.org/pub/scm/git/git.git/tree/builtin/submodule--helper.c?id=e8d0608944486019ea0e1ed2ed29776811a565c2#n2679\n\n"}]}