I've read how to remove a git submodule myself:
# Delete the relevant section from the .gitmodules file.
git config -f .gitmodules --remove-section submodule.$submodulepath
# Delete the relevant section from .git/config
git config -f .git/config --remove-section submodule.$submodulepath
git rm --cached path_to_submodule # no trailing slash
git commit
rm -rf path_to_submodule
I can do that. But when someone else does a git pull
how do we ensure that the submodule is then removed from their system? The .gitmodules
change comes with the pull, but not much else as far as I can tell. So the person who pulled would then still have to run
git config -f .git/config --remove-section submodule.$submodulepath
rm -rf path_to_submodule
Is that right? On a small development team I guess you could just tell everyone to run those commands, but it's less than ideal.
Is there some magic command that automates this? In particular I'd like some standard way of automating this in deployment scripts. Off the top of my head I'm not sure how the scripts would even know that there was one less submodule than there previously was. (Not particularly attractive) options that occur to me are:
- doing diffs on
.gitmodules
before and after pull - delete all submodules and then run
git submodule update --init
every single deploy. - The submodule does end up being an untracked file after the pull, so an option that would work would be to delete all untracked directories that contain a
.git
subdirectory after a pull, but you're liable to delete stuff you wanted to keep that way.
Any better options appreciated.