"Kalyan Sriram" [off-list ref] writes:
"git rm" deletes the submodule directory completely and modifies
.gitmodules, effectively removing the submodule. However, it leaves the
entry in .git/config dangling, which is annoying.
The entry is not dangling. It is there to be used when you go back
in history.
"git submodule deinit" (which I didn't know existed until I just read the man
page) deletes all contents of submodule directory, but leaves the
(empty) submodule directory itself intact. It DOES delete the entry in
.git/config, but leaves a dangling entry in .gitmodules, so the next
"git submodule update --init --recursive" registers and populates the
submodule again.
"deinit" is *not* about remove a submodule. A project can be
checked out and used with or without its submodules instantiated,
and "git submodule init" is a way to instantiate it. "deinit" is
its opposite. As far as the history (which has already been
recorded in the repository, and the history that will be recorded
in the repository starting from that state) is concerned, the
submodule is there---it's just that you are not interested in it and
chose not to check it out.
So "git rm" seems to be doing exactly what "git submodule rm" should
be doing, nothing more, nothing less.
On Fri Oct 22, 2021 at 3:02 PM PDT, Junio C Hamano wrote:
"Kalyan Sriram" [off-list ref] writes:
quoted
"git rm" deletes the submodule directory completely and modifies
.gitmodules, effectively removing the submodule. However, it leaves the
entry in .git/config dangling, which is annoying.
The entry is not dangling. It is there to be used when you go back
in history.
quoted
"git submodule deinit" (which I didn't know existed until I just read the man
page) deletes all contents of submodule directory, but leaves the
(empty) submodule directory itself intact. It DOES delete the entry in
.git/config, but leaves a dangling entry in .gitmodules, so the next
"git submodule update --init --recursive" registers and populates the
submodule again.
"deinit" is *not* about remove a submodule. A project can be
checked out and used with or without its submodules instantiated,
and "git submodule init" is a way to instantiate it. "deinit" is
its opposite. As far as the history (which has already been
recorded in the repository, and the history that will be recorded
in the repository starting from that state) is concerned, the
submodule is there---it's just that you are not interested in it and
chose not to check it out.
So "git rm" seems to be doing exactly what "git submodule rm" should
be doing, nothing more, nothing less.
That makes sense, thanks for the clarification. So it looks like there
isn't any work to be done here after all?
What are your thoughts about aliasing git submodule rm to git rm?
Thanks,
Kalyan