i wish git would implement a built in subsplit feature
I Hate Git Submodules
21–30 of 73 posts
Re: I Hate Git Submodules
#22I've been the git fixer for a few different teams. I want to like submodules, but there's something that doesn't fit my brain the way the rest of git does. It feels half-baked. I think we're still missing the best way to model the problem as a tree of related states.
[deleted]
Re: I Hate Git Submodules
#23I've been the git fixer for a few different teams. I want to like submodules, but there's something that doesn't fit my brain the way the rest of git does. It feels half-baked. I think we're still missing the best way to model the problem as a tree of related states.
Agreed. I also want to like submodules but every encounter with them has been an awkward confusing mess.
They're fine if they are completely hidden from human interaction and used in a programmatic way, but the human interface with the concept seems to always be so awkward.
Re: I Hate Git Submodules
#24Everybody hates git submodules.
Re: I Hate Git Submodules
#25What do people think of git subtrees? https://codewinsarguments.co/2016/05/01/git-submodules-vs-gi... Or the non-standard git-subrepo? https://github.com/ingydotnet/git-subrepo
Terrible. You can't tell that they are there and no tool support in remembering the remote.
Re: I Hate Git Submodules
#26I also hate monorepos. I consider the monorepo to be an anti-pattern.
It's an architectural advantage to separate each module into a different repo as it encourages careful separation of concerns.
If you find that you often need to update many modules together every time you want to add a new feature to your project, this is often an indication that your modules do not have proper separation of concerns and your abstractions are leaking. It means your project exhibits low cohesion and/or tight coupling between modules.
The difficulty in maintaining separate module dependencies is actually a very useful signal to you as a developer that your code is too tightly coupled and needs to be refactored into modules which are more independent.
Monorepos are a bandaid patch solution which covers up the root problem. The real problem is incorrect separation of concerns, AKA low cohesion which leads to tight coupling between your components.
It's not possible to design simple interfaces between components when these components have overlapping responsibilities.
Re: I Hate Git Submodules
#27[deleted]
Re: I Hate Git Submodules
#28I was hoping to see better solutions to this problem in the comments, but the paucity of a solid solution means the problem isn't solved yet. I agree with `qznc` below, in that once maturity is achieved, the monorepo should x-furcate and create packages, but up until that point there really is no clean solution for this relational concept.
Re: I Hate Git Submodules
#29I've been maintaining a git repo at my current and previous employer - both started out with submodules, and got axed due to added complexity and cognitive load. After removal, they were not missed. Case closed.
Re: I Hate Git Submodules
#30You spend all this time figuring out how to make git do what you want using this general format:
git [args]
git submodule [args]