Issue with removing a git submodule

Question

I have a question regarding removing git submodules. I'm organizing my config files and vim bundles using git, with the vim bundles as submodules. Now I'm trying to remove a submodule (per the instructions here, but I'm not succeeding.

--git submodule deinit -f vim/bundle/snipmate-snippets
Submodule work tree 'vim/bundle/snipmate-snippets' contains a .git directory
(use 'rm -rf' if you really want to remove it including all of its history)

So I try rm -rf...

--git rm -rf vim/bundle/snipmate-snippets
error: the following submodule (or one of its nested submodules)
uses a .git directory:
    vim/bundle/snipmate-snippets
(use 'rm -rf' if you really want to remove it including all of its history)

What is it that I'm doing wrong? Obviously just doing rm -rf like git is telling me to won't be good enough since the submodule entries in the .gitmodules file will stay. Thanks.

Answer 1

You need to rm -rf without the git:

rm -rf vim/bundle/snipmate-snippets

Then you can deinit the submodule:

git submodule deinit vim/bundle/snipmate-snippets

Answer 2

You won't have this error message anymore with Git 2.12 (Q1 2017)

See commit 55856a3 (27 Dec 2016), and commit 83b7696, commit 5a1c824, commit bd26756 (20 Dec 2016) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit 3ccd681, 18 Jan 2017)}

rm: absorb a submodules git dir before deletion

"git rm" used to refuse to remove a submodule when it has its own git repository embedded in its working tree.
It learned to move the repository away to $GIT_DIR/modules/ of the superproject instead, and allow the submodule to be deleted (as long as there will be no loss of local modifications, that is).

When deleting a submodule, we need to keep the actual git directory around, such that we do not lose local changes in there and at a later checkout of the submodule we don't need to clone it again.

Now that the functionality is available to absorb the git directory of a submodule, rewrite the checking in git-rm to not complain, but rather relocate the git directories inside the superproject.

This is what the new test "rm of a populated nested submodule with a nested .git directory fails even when forced" now illustrates.

---

With Git 2.35 (Q1 2022), the error message really disappear: "git submodule deinit"^(man) for a submodule whose .git metadata directory is embedded in its working tree refused to work, until the submodule gets converted to use the "absorbed" form where the metadata directory is stored in superproject, and a gitfile at the top-level of the working tree of the submodule points at it.

The command is taught to convert such submodules to the absorbed form as needed.

See commit 0adc8ba (19 Nov 2021) by Mugdha Pattnaik (mugdhapattnaik).
^{(Merged by Junio C Hamano -- gitster -- in commit 670703e, 10 Dec 2021)}

submodule: absorb git dir instead of dying on deinit

^{Suggested-by: Atharva Raykar
Signed-off-by: Mugdha Pattnaik}

Currently, running 'git submodule deinit'^(man) on repos where the submodule's '.git' is a directory, aborts with a message that is not exactly user friendly.

Let's change this to instead warn the user that the .git/ directory has been absorbed into the superproject.
The rest of the deinit function can operate as it already does with new-style submodules.

In one test, we used to require "git submodule deinit" to fail even with the --force option when the submodules .git/ directory is not absorbed.
Adjust it to expect the operation to pass.