Shourya Shukla <periperidip@xxxxxxxxx> writes: > So, my question is, do we need to fix this to make sure that the changed > '.gitmodules' is staged? When "--cached" is given, the user is asking the module to be removed ONLY from the index, without removing it from the working tree, no? So I think ".gitmodules" in the working tree should not be touched at all. Removing the entry for the module from the ".gitmodules" registered in the index, when a submodule registered in the index, might be desirable, and what you say here > And its entry is not removed from the file. What should be done about > this? I would appreciate your opinions. may be related to it. But I doubt it is a good idea to let "git rm" be the one touching ".gitmodules" either in the index or in the working tree for that to happen. The reason I am hesitant to teach anything about ".gitmodules" to the basic level tools like "add", "rm" is because I consider, while the "gitlink" design that allows the tip-commit from a submodule in the superproject is a good thing to be done at the structural level in the core part of Git, administrative information stored in the ".gitmodules" is not part of pure "Git" and alternative designs on top of the core part of Git that uses different strategy other than what we have are possible and they could even turn out to be better than what we currently have. In other words, I have this suspicion that the ".gitmodules" based submodule handling we currently have, done using "git submodule" command, should not be the only and final form of submodule support Git would offer. That leads me to think that anything that touch ".gitmodules" should be done with "git submodule" suite of commands, not by the low level "add", "rm", etc. Such a separation of concern would allow a new "git submodule2" design that may be radically different from the current ".gitmodules" one to be introduced, possibly even replacing, or living next to each other, the current "git submodule" together with ".gitmodules" file, without affecting the low-level "add", "rm" tools at all. So from that point of view, if we were to fix the system, it may be preferrable to make "git rm [--options] <submodule>" only about the submodule in the working tree and/or the index, without touching ".gitmodules" at all, and let "git submodule rm [--cached] <submodule>" be the interface on top. The implementation of "git submodule rm [--cached]" may use "git rm [--cached]" internally as a building block to deal with the index and/or the working tree, but the info kept in ".gitmodules" for administrative reasons should be dealt within "git submodule" without exposing any such policy to the lower level tools like "git rm" and "git add". Having said all that, please do not take anything I say about submodule design as the final decision. It is just an opinion by one development community member (i.e. me) and there are a lot more people who are heavily invested in the current design and interested in improving it than I am. Thanks.
