Re: [RFC] [BUDFIX] 'git rm --cached <submodule>' does not stage the changed .gitmodules

[Shourya Shukla <periperidip@gmail.com>]

On 07/02 11:30, Junio C Hamano wrote:
> Shourya Shukla <periperidip@gmail.com> 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