Submodules look cool but in reality they’re hot as hell.
This article briefly shows why people want to use submodules and in the section after why they shouldn’t use them.
When git users come across submodules the first time they look attractive and nice because they seem to be one way to better structure a project where some parts could be put in their own repositories.
Essentially most people’s intention is to extract some parts in a way that other people can get a copy of this little part without the need to become familiar with the whole project structure.
Submodules would put a smile on people’s faces if there weren’t some issues.
#1: Submodule Update
git submodule update changes in a submodule are silently overwritten instead of merging them.
#2: See changes made in the whole project …
… or not.
In the parent (root) repository
git status shows changes in this parent repository but it does not include changes of submodules. Instead it says something has changed in this submodule.
If submodules have a strong relationship to each other it’s hard to track changes across multiple submodules.
#3: Your history will be broken
In the following the commits 89c99bc and 3e0b43e are updates of submodule references.
89c99bc Documentation update b9bd1d1 New helper to make columns from an array. 0cce430 New: helper functions 3e0b43e Directory code improved
A reference update means that you (could) have made a lot of changes in submodules but in the parent git repository these changes show up in one single message, essentially describing that you updated the reference.
The repo history simply breaks and this is just another thing that makes your life harder. Just imagine that bugfixing also includes commit messages to be read.
#4: Using Git in the shell only
In a shell only there’s more work with a repository using submodules than with a repository with no submodules.
Scenario: files in different submodules must be changed and the main repository updated to keep these changes together when pulling from the main repository on another client.
Steps to be done:
cd submodule1 git add file1 file2 git commit -m "some changes in submodule1" git push cd ../submodule2 git add file3 file4 git commit -m "some changes in submodule2" git push cd .. git add submodule1 submodule2 git commit -m "Updated submodule1 and submodule2" git push
Steps to be done if no submodules are involved:
git add submodule1/file1 submodule1/file2 submodule2/file3 submodule2/file4 git commit -m "I made this and that" git push
The extra work comes from: first commit all the changes in your submodules!
Avoid submodules if you don’t need them. They don’t simplify your life – on the contrary you’ll have more work and trouble in certain situations.
Other people are experiencing the same or quite similar:
- Why your company shouldn’t use Git submodules
- Git submodules are probably not the answer
- How to use git submodules with developers not familar with git?
You also need to teach new project team members: