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

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 https://github.com/deanturpin/dft.git 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.