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.