On 07/02 11:30, Junio C Hamano wrote: > 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. We can remove the entry of the SM from the '.gitmodules' at least no? Since the SM won't be relevant to us. At the end an empty '.gitmodules' file would stand. > 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". Hmmmm.. You are correct here. But, won't we be replicating the functionality of 'git rm [--options] <submodule>' when we create another new command say 'git submodule rm [--options] <submodule>'. I might be being a bit naive here so take this with a grain of salt. For now, we could make sure that the submodule does not have a trace in the '.gitmodules' for the very least, no? > 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. Yeah, I will tag along a couple of others who I think might help. Thank you for your opinion BTW :) Thanks, Shourya Shukla
