aboutsummaryrefslogtreecommitdiff
path: root/Documentation/git-rm.txt
diff options
context:
space:
mode:
authorJens Lehmann <Jens.Lehmann@web.de>2013-08-06 21:15:25 +0200
committerJunio C Hamano <gitster@pobox.com>2013-08-06 14:11:00 -0700
commit95c16418f0375e2fc325f32c3d7578fba9cfd7ef (patch)
tree70eda70133f2ad444a1040af0ede8f28b85ac749 /Documentation/git-rm.txt
parent0656781fadca17cc51fb1c30f265c251ebe12819 (diff)
downloadgit-95c16418f0375e2fc325f32c3d7578fba9cfd7ef.tar.gz
git-95c16418f0375e2fc325f32c3d7578fba9cfd7ef.tar.xz
rm: delete .gitmodules entry of submodules removed from the work tree
Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/git-rm.txt')
-rw-r--r--Documentation/git-rm.txt8
1 files changed, 5 insertions, 3 deletions
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 1d876c261..9d731b453 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -134,14 +134,16 @@ use the following command:
git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
----------------
-Submodules
-~~~~~~~~~~
+SUBMODULES
+----------
Only submodules using a gitfile (which means they were cloned
with a Git version 1.7.8 or newer) will be removed from the work
tree, as their repository lives inside the .git directory of the
superproject. If a submodule (or one of those nested inside it)
still uses a .git directory, `git rm` will fail - no matter if forced
-or not - to protect the submodule's history.
+or not - to protect the submodule's history. If it exists the
+submodule.<name> section in the linkgit:gitmodules[5] file will also
+be removed and that file will be staged (unless --cached or -n are used).
A submodule is considered up-to-date when the HEAD is the same as
recorded in the index, no tracked files are modified and no untracked