3 ms·

I will probably get whipped for this, but what about submodules? If I am working on a bigger project with multiple smaller projects I create a folder structure

I will probably get whipped for this, but what about submodules? If I am working on a bigger project with multiple smaller projects I create a folder structure locally anyway! I can commit them too and when pulling I can just choose to only pull the one submodule instead of all of them? Working on them is essentially the same, you just need to update the main repo once in a while or run git pull independently.

sirwhinesalot 5y ago
You had 1 problem: Too many git repos. Now you have 2 problems: Too many git repos + a monorepo on top of all those repos. We tried this where I work to solve the issue of having 10x more git repos than people on the team. We got rid of the submodules as fast as we introduced them, they solved nothing and only caused more headaches. If you want to switch to a monorepo while retaining the history of the multi-repos, use git subtree. You want to get rid of the other repos, not keep them around.
- jhoelzel 5y ago
  you could create submodules of submodules to make an ever lasting chain too :D tbh I believe this is an organisational problem and the usefullness of the monorepo just has to be questioned in this case. If you had lets say 30 devs in your org, there would have been 300 repositories. Since they are only containers for something, the question is what does each repo actually represent? What we are trying to do is to ogranize things that belong together therefore I suggest a domain driven approach where stuff that belongs together is simply grouped together. kind of like a workspace is anyway in the end. eg: Org - Infra - DB-Servers - App-Servers - xyz Servers - App1 -x -x - App2 - etc Now the questions I would like to throw into the room is that if you need all repositories in order to build the software in front of you at the same time: why has it not been a monorepo to begin with? Subtress do seem to be the answer here I completely agree. At lesat this way you have -some- possibility to work on a subset of the code. But if you use libraries/modules/pacakges to build the product, no matter what language, testing and integration should be done on the package level, even if at least at first anyway right? So its not really a tech problem, but an organitational one. What Submodules give you, is a repository that acts kind of like a readme, and you can even deploy documents alongside those submodules easily. By adding and removing ohter repositories you are also given the possiblity to fade out tech you are no longer using and with things like background ci workers you can even keep it nicely updated. Basically built by tech to be used by humans. edit: I forgot to mention, that if one of those repos is on github, it for instance does not need to be cloned locally but can simply be clicked with a mouse and in the end you clone the repository you would like to work on.
  - sirwhinesalot 5y ago
    All very true, I'm not suggesting a monorepo for the whole org (that's dumb) but per project. If you have libraries shared across different applications, treat those libraries as fully independent products. No different from something you'd download from NPM. Anything else is too tightly integrated, and if it is tightly integrated, you want a monorepo, not a repo with submodules. edit: At least for C++ I typically use submodules to store libraries from their own git repos, but these are very carefully versioned. If there's a good package management solution for the language, this is typically not necessary.
duped 5y ago
Git submodules are only a viable tool for truly external dependencies that need to be built from source, in which case adding a submodule and special case for your configure/make scripts is one of the easiest ways to add a dependency to your project. If you're using it for dependency management for internal projects you're going to have a bad time. Especially as things get more complex. The only advantage is if you need to keep particularly components open source. Otherwise just use a mono repo.

sirwhinesalot 5y ago

You had 1 problem: Too many git repos. Now you have 2 problems: Too many git repos + a monorepo on top of all those repos. We tried this where I work to solve the issue of having 10x more git repos than people on the team. We got rid of the submodules as fast as we introduced them, they solved nothing and only caused more headaches. If you want to switch to a monorepo while retaining the history of the multi-repos, use git subtree. You want to get rid of the other repos, not keep them around.

jhoelzel 5y ago
you could create submodules of submodules to make an ever lasting chain too :D tbh I believe this is an organisational problem and the usefullness of the monorepo just has to be questioned in this case. If you had lets say 30 devs in your org, there would have been 300 repositories. Since they are only containers for something, the question is what does each repo actually represent? What we are trying to do is to ogranize things that belong together therefore I suggest a domain driven approach where stuff that belongs together is simply grouped together. kind of like a workspace is anyway in the end. eg: Org - Infra - DB-Servers - App-Servers - xyz Servers - App1 -x -x - App2 - etc Now the questions I would like to throw into the room is that if you need all repositories in order to build the software in front of you at the same time: why has it not been a monorepo to begin with? Subtress do seem to be the answer here I completely agree. At lesat this way you have -some- possibility to work on a subset of the code. But if you use libraries/modules/pacakges to build the product, no matter what language, testing and integration should be done on the package level, even if at least at first anyway right? So its not really a tech problem, but an organitational one. What Submodules give you, is a repository that acts kind of like a readme, and you can even deploy documents alongside those submodules easily. By adding and removing ohter repositories you are also given the possiblity to fade out tech you are no longer using and with things like background ci workers you can even keep it nicely updated. Basically built by tech to be used by humans. edit: I forgot to mention, that if one of those repos is on github, it for instance does not need to be cloned locally but can simply be clicked with a mouse and in the end you clone the repository you would like to work on.
- sirwhinesalot 5y ago
  All very true, I'm not suggesting a monorepo for the whole org (that's dumb) but per project. If you have libraries shared across different applications, treat those libraries as fully independent products. No different from something you'd download from NPM. Anything else is too tightly integrated, and if it is tightly integrated, you want a monorepo, not a repo with submodules. edit: At least for C++ I typically use submodules to store libraries from their own git repos, but these are very carefully versioned. If there's a good package management solution for the language, this is typically not necessary.

duped 5y ago

Git submodules are only a viable tool for truly external dependencies that need to be built from source, in which case adding a submodule and special case for your configure/make scripts is one of the easiest ways to add a dependency to your project. If you're using it for dependency management for internal projects you're going to have a bad time. Especially as things get more complex. The only advantage is if you need to keep particularly components open source. Otherwise just use a mono repo.