Are they really that bad? [Spoiler alert: yep, worse than you can imagine.]

Adding submodules

Clone an existing repo and update the submodules - note the hashes against folders in the repo.

git submodule init
git submodule update

Add a new submodule by HTTPS.

$ git submodule add
Cloning into '/home/deant/deps-submodules/dft'...
remote: Enumerating objects: 1417, done.
remote: Total 1417 (delta 0), reused 0 (delta 0), pack-reused 1417
Receiving objects: 100% (1417/1417), 17.58 MiB | 13.17 MiB/s, done.
Resolving deltas: 100% (832/832), done.

Commit the updated module config and the new submodule dir which will be actually be pushed as an empty dir and updated by the update command above.

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   .gitmodules
        new file:   dft

Making changes

You need to remember to tell the top level to push changes in submodules. But after that it does feel like an atomic push to all servers. But if you forget you can fix it by running git push in each submodule.

git push --recurse-submodules=on-demand

One thing you must be careful of is syncing before you’ve committed your changes. Because they will be gone.

Bash config - always list submodule diffs

git config --global diff.submodule log

Deleting submodules

Well this all seems very complicated.