BUG: Removing a submodule with --cached doesn't stage changes to the .gitmodules file

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