Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > Am 05.07.2012 02:44, schrieb Junio C Hamano: > ... >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html