3 ms·

We have been using this since it was announced for our main repository. (The author of git-subtrac is my cofounder.) It is a definite improvement on storing sub

We have been using this since it was announced for our main repository. (The author of git-subtrac is my cofounder.) It is a definite improvement on storing submodules in separate repositories, where one of us would forget to push a commit and the other of us would have to wait for them to be online to get it. There is still more needed to make git submodules a pleasant user experience, but this was a big missing piece of the puzzle. (Submodules mean to you need to know a ton about how git works before you can do even the most basic things.)

unqueued 7y ago
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...

unqueued 7y ago

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...