"git submodule update --init --recursive does not know exactly where to checkout the submodules"
okay, what am I missing?
Because at a glance, the obvious solution literally enabled by having multiple worktrees is to give each submodule a linked worktree in each of the parent repo's linked worktrees.
The notion of giving each submodule a linked worktree in each of the parent repository's linked worktrees is theoretically sound and would seem to provide a structured and organized solution. That arrangement could indeed mirror the structure of the parent repository's worktrees, providing a clean, hierarchical arrangement that keeps submodule work isolated within the scope of each parent worktree.
However, implementing this idea presents some challenges and complexities due to the way Git handles submodules and worktrees.
-
Configuration Complexity: Implementing a system where each submodule has a linked worktree for every worktree of the superproject can become quite complex. The configuration and management of such a setup would require a good understanding of both Git worktrees and submodules. It could become difficult to manage, especially in repositories with a large number of submodules and worktrees.
-
Disk Usage: Each worktree is a full checkout of the repository, and each submodule within those worktrees would also be full checkouts. That could lead to significant disk usage, especially in projects with large submodules or a large number of submodules.
-
Synchronization and Consistency: Maintaining consistency and synchronization across multiple worktrees and submodules could become challenging. For instance, ensuring that submodule references are correctly maintained across all worktrees, and that updates to submodules are properly propagated to all relevant worktrees.
-
Operational Overhead: The operational overhead of managing multiple worktrees for both the superproject and its submodules might outweigh the benefits. That includes not just disk space, but also the computational resources and time needed to initialize, update, and manage these worktrees.
-
Tooling Support: The existing Git tooling might not fully support or streamline the process of managing such a complex setup. Custom tooling or scripts might be needed to efficiently handle the creation, deletion, and synchronization of worktrees and submodules.
-
Error Prone: The more complex the setup, the more prone it is to errors. Users might find themselves facing unexpected behaviors, especially if they are not well-versed in the intricacies of Git submodules and worktrees.
-
Git Version and Feature Limitations: Depending on the version of Git, certain features necessary to manage such a setup smoothly might not be available. As seen in the provided information, several issues were only addressed in more recent versions of Git.
The concept is appealing for its structural clarity, but the practical implementation within the current Git framework might present challenges that could deter teams from adopting such a setup.