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
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
Well this all seems very complicated.