Cool! This is a problem I've been trying to solve. One of my biggest annoyances was how you may have multiple submodules that are tightly related to your proje

Cool! This is a problem I've been trying to solve. One of my biggest annoyances was how you may have multiple submodules that are tightly related to your project, but have to be in external repos that may not logically map well. One trick I started doing was to put the actual submodule repos physically inside my parent repos on my server, and then in my .gitmodules, using the relative directory like ./submodule1.git So, that means: parent/ --> server:parent.git parent/submodule1/ --> server:parent.git/submodule1.git I have also been using orphan worktrees as well. The reason this is such a big deal, is that for many of the data projects I work on, the different repos, while closely related, should really have completely separate history. This is because I use tools like git-annex and git-lfs to access and push large datasets within git, and it would make no sense at all to mix that in with documentation and code. I sometimes use Datalad, which handles a lot of this, but had some of its own quirks and can be overkill some times. I'm certain to give this a try. Such as: parent/ imaging_input/ (12G of 50G checked out w/ git-annex) imaging_diffs_input/ (5G git-lfs) imaging_output (git-annex) logs_output/ (git-annex) code/ wiki/ [1]: http://handbook.datalad.org/en/latest/basics/101-106-nesting.html http://handbook.datalad.org/en/latest/basics/101-106-nesting...