Re: [RFC PATCH 0/2] Teach rm to better handle submodules

Jens Lehmann [off-list ref] writes:

Am 05.07.2012 02:44, schrieb Junio C Hamano:
...

quoted

I wouldn't claim that I have thought things through yet, but in
general my instinct tells me that it is a bad idea to try pushing
down "submodule management" related bits to the core.

Am I right assuming you are only talking about 2/2 here and not
about the bugfix in 1/2?

I was addressing the general attitude, expressed in your [0/2] cover
letter, of eagerly attempting to push down to the core side what
could be affected by non-core policy, namely, things like what is in
".gitmodules" and how the working trees and controlling repositories
of submodules are laid out (cf. the other thread on GIT_WORK_TREE
and GIT_DIR used for the top-level superproject).  The comment was
not about either of the two patches.

When making a project-wide structural change to the superproject by
adding a submodule, "git submodule add" is used to add optional
information in .gitmodules, because where the other people would
clone the history for the submodule (or if there is a place for
other people to fetch it in the first place---a private standalone
project does not even need one) is not something the core "git add"
is not interested in.  Ceasing to use a submodule project wide (the
use case (1) in the message you are responding to) by removing the
submodule tree and an entry in .gitmodule for it is the same kind of
project wide structural change, and it felt very out of place, at
least to me, to have "git rm" do anything with .gitmodules file.