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

Shourya Shukla [off-list ref] writes:

On 07/02 11:30, Junio C Hamano wrote:

quoted

Shourya Shukla [off-list ref] writes:

quoted

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

quoted

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.

quoted

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