So far git submodules are working for centralized code that repeats in use across repos and even organizations, and doesn’t change much.
But one thing I run into constantly is where the code is for a repo I’ve just cloned that has a submodule, and even new repos as we re-architect some of our builds.
Decouplign the pieces of the code has required things like taking the original repo that had ansible role code plus python application code plus pipeline build code, and creating a new repo, syncing the contents over and then reworking it as, say, ansible_role-nebula-utils-api (ansible role code), nebula-utils-api (pythonic app code) and jenkins-nebula-util-api (the over-arching pipeline build code). But an rsync fails to copy over the submodule (and the rsync excludes the .git directory, so submodules aren’t yet configured inside the new repo). That requires re-instantiating the submodule.
git submodule add git@github.server:NebulaGM/orion-installer.git
But then after that some developer clones the repo and doesn’t see the submodule code at all…
git clone doesn’t by itself grab the actual submodule code. You can use –recurse-submodules.
git clone --recurse-submodules
At the time you clone the repo itself. But – I usually forget that right now – what if you clone the repo and don’t add –recurse-submodules?
The following pulls in the code.
git submodule update --init --recursive
One more that keeps recurring – removing a submodule…
vi .gitmodules # remove entry for submodule vi .git/config. # remove submodule entry if present git rm --cached orion-installer rm -rf .git/modules/orion-installer
— doug