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

[Junio C Hamano <gitster@pobox.com>]

Shourya Shukla <periperidip@gmail.com> writes:

> 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.

I agree that .gitmodules needs to be modified in the index (but not
in the working tree) to make things consistent in the worldview of
"git submodule" subsystem.  I am just saying that I doubt "git rm"
is a good place to perform an operation that is required only by the
particular kind of submodule design (namely, "git submodule" that
works with ".gitmodules"), as I said below.

>> The reason I am hesitant to teach anything about ".gitmodules" to
>> the basic level tools like "add", "rm" is because ...
> ...
> 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>'.

Well, that is what I meant by "'git submodule rm [--cached]' may use
"git rm [--cached]" internally as a building block".  

When a better design of submodule subsystem appears, it might or
might not use ".gitmodules", but when it wants to remove the
submodule only from the index, it would do so by internally calling
"git rm --cached" to implement that part of the feature, in addition
to its own bookkeeping.

It won't be a replication of the functionality---dealing with the
index and working tree would be done by "git rm" called by "git
submodule rm".