Removing a submodule with --cached doesn't stage changes to the .gitmodules file
Command: `git rm [--cached] some_submodule`
Behavior without `--cached`: - `some_submodule/` is deleted. - The entry for `some_submodule` is deleted from `.gitmodules`. - Both changes are staged.
Expected behavior with `--cached`: - Neither `some_submodule` nor `.gitmodules` are actually modified in the work tree. - `some_submodule` is staged for deletion. - `.gitmodules` is staged for modification (removal of the entry for `some_submodule`).
Actual behavior with `--cached`: - Neither `some_submodule` nor `.gitmodules` are actually modified in the work tree. - `some_submodule` is staged for deletion. - **`.gitmodules` is not staged for modification.**
Git version: Seen on git 2.25 (Linux) and 2.16 (Windows)
Workaround: - I had to `mv` the directory outside of the project, `git rm -f` it (without `--cached`), and then `mv` it back into the project in order to have `.gitmodules` changed without actually deleting the `some_submodule/` subdirectory. - Alternatively, manually edit `.gitmodules` and remove the submodule (this isn't a viable option for automated scripts, and can be a bit inconvenient when the `.gitmodules` file is too big).
Example code:
``` mkdir some_submodule cd some_submodule git init echo hello > hello.txt git add hello.txt git commit -m 'First commit of submodule' cd .. mkdir top_repo cd top_repo git init echo world > world.txt git add world.txt git commit -m 'First commit of top repo' git submodule add ../some_submodule git status # both some_submodule and .gitmodules staged git commit -m 'Added submodule' git rm --cached some_submodule git status # only some_submodule staged ```
Best regards,
Javier Mora