Am 05.07.2012 02:44, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> This is a follow-up to gmane thread 200564 about teaching "git >> submodule" the "rm" command. It has the intention to only having >> to add a small amount of new code to the submodule script while >> handling the heavy lifting in core git. >> >> With this series I also intend to make submodule handling a bit >> easier for users by teaching "git rm" to remove the submodule >> section from the .gitmodules file, no matter if the submodule is >> populated or not. Not being able to do that because the section >> is not found there or the .gitmodules file is already deleted >> will only issue a warning (with the intent to make the user aware >> that "git rm" would do that for him in case he did that himself). > > 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? > Let me think aloud about removing a directory, in a checkout of a > superproject, that has a submodule checkout. There are at least two > majorly different reasons a user wants to do this: > > (1) The project used to bind a submodule as a part of the > superproject there, but it no longer wants to do so (e.g. we > used to ship compiler toolchain as part of our embedded > appliance superproject, but from this release on, we expect > developers to install the toolchain on their own). We want to > remove the submodule directory, we want to remove the submodule > entry in the superproject's tree, and we want to remove the > submodule entry from .gitmodules file. > > (2) One particular project participant has been working on one part > of the superproject, say "the documentation submodule", hence > "submodule init" was used for that submodule part to populate > it. Since the participant has done with the work, there is no > longer need to keep the submodule checkout (submodule uninit?), > and getting rid of it makes the working tree leaner and "git > pull" faster (as there is no longer need to fetch updated > history in the uninteresting submodule). We just want to > remove the contents of the submodule directory. We do want to > keep the index entry for the submodule in the superproject. We > do want to keep the .gitmodules intact. > > This kind (1) of reorganization hopefully is rare (in other words, > you wouldn't drop a submodule today and turn around to add it again > tomorrow), done by one person and the result is propagated to all > other project participants. On the other hand, (2) can be done by > any and all participants of the project at any time. > > Which audience should "git rm $path" serve? My gut feeling is that > the "project structure change" part that goes beyond the core > (e.g. what is in ".gitmodules") and should be a rare flag-day event > deserves a separate command, if only to make the user aware that the > user is invoking a heavy-weight (from the point-of-view of the > workflow) operation. Yes, "git rm" is for case (1) where someone wants to remove a submodule from the project with the commit he prepares. Case (2) is not addressed at all by this series (but I like the "uninit" idea, makes lots of sense to me). > I am not convinced that "git rm $path" is a good interface for (2), > though. For one thing, you would need to keep an empty directory at > the submodule path for the purpose of (2), so it is not really "rm". I totally agree here. > Perhaps "git submodule uninit" might be needed to support (2), in > addition to "git submodule rm" to support (1). I think we should, as doing a simple "rm -rf $path" won't do the job as you already pointed out. First git status will complain that $path has been deleted, so you'll have to manually recreate an empty directory there. And then you'll also have to revoke your interest in having that submodule populated by removing the submodule.name entry from .git/config, or the next "git submodule update" will happily re-populate the submodule. All that should be handled by a "git submodule uninit" (including the tests for submodule modifications that could be lost). I don't see any core git command where such a functionality could sanely live. But that is subject to another patch. Here I wanted to get some feedback if submodule users would agree with me that a "git rm" should remove a submodule from index *and* .gitmodules (because they want to remove it from future versions of the repo, and then the removal from .gitmodules should happen at the same point in time, so rm could just do it for you). I don't have strong feelings about the decision if only the submodule script should do any modifications to .gitmodules or if it belongs into git core as part of the rm command, though for me the latter feels more natural. -- 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