Comment by kccqzy
12 hours ago
Git submodules aren’t convenient either. For the silo and corporate development use case, just use multiple repositories and make your build tool aware of multiple repositories. It is slightly less painful than submodules.
I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
That and a way to recursively commit/push (i.e. make a change within a submodule, commit in one step with the same message in the parent submodule).
Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to:
1. Change the file
2. Commit within the submodule
3. Push the submodule
4. add the submodule change in the outer repo
5. commit in the outer repo
6. push the outer repo
You can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.
You can set submodule.recurse to true and then git commands operate as if you passed --recurse to them? It's just that most people don't actually want that, because a submodule is generally something you intentionally want to handle separate.
git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.
To add to this, you can add in your .gitmodules the name of the branch that the --remote flag will follow. It just works.
[dead]
Submodules ARE multiple repositories. This is not an either or.
I understand that. I am just arguing that making your build tool aware of multiple repos is enough; no need to use submodules in git and make your build tool pretend to operate on a single repo.