UPDATE: Apparently it’s not so tricky now. http://stackoverflow.com/a/14405542/555384
I’ve found an issue in the way git handles the situation in which you want to remove a submodule from a location and add a different submodule in the same location. Replacing the submodule with a different repository entirely.
What is a submodule?
It is nothing more than a directory location matched up with a specific commit reference in an external repository.
The actual backing repository is stored in the parent’s
.git/modules/<path/to/submodule> directory. So when you interact with a submodule, this is the location you are actually interacting with, as the
.git file in the submodule directory, simply points to it’s actual location within the parent’s
This is the (cannonical?) way to remove a submodule (via this SO Answer)…
To remove a submodule you need to:
- Delete the relevant section from the
- Delete the relevant section from
git rm --cached path_to_submodule(no trailing slash).
- Commit and delete the now untracked submodule files.
It’s important to note that these steps remove the submodule’s reference in the current working tree at this point in the repository’s history, but they do not remove the backing repository from within the parent’s
So the actual submodule repository still exists in the repository. This is good and important to note because previous commits need access to this repository to reference the state in which this submodule was a part of the working tree.
If you now try and re-add a different repository in the same location, git assumes you are re-instating the previous repository and attaches the old repository as the backing repository, even though your
.gitmodules file references a completely different repository.
I reported this issue and it is currently being discussed in the git development mailing list, hopefully it will be resolved soon.