On Wed, Jul 8, 2009 at 1:41 PM, Tim Henigan<tim.henigan@xxxxxxxxx> wrote: > Hello, > > I recently encountered a situation where a user wanted to remove a submodule > from a repository. Searching the mail archive, I found this thread > [1], but it does > not appear that it was ever followed up. > > The Git Submodule Tutorial [2] has instructions for removing submodules, but it > seems natural to teach git how to "submodule rm". > > This change would require git-submodule.sh to: > 1. Modify the .gitmodules file (remove the entry for the submodule). > 2. Modify the .git/config file (remove the entry for the submodule). > 3. Delete the newly untracked files. > Submodules are tracked by the tree. You'll need to 'rm -rf' the submodule, and then 'git rm' the folder to remove it. > Another option to consider would be a "submodule rm --cached" option which would > keep the newly untracked files. However, with this option, I believe > it should still > descend into the submodule directory to remove the leftover submodule > ".git" folder. > > Is there another way of doing this? If not, does this sound like a > reasonable change? I can think of the only opposition being how blatantly dangerous it would be. You're creating a command that will nuke the whole repository, along with any unpushed changes. There's potential there for someone to seriously injure themselves without realizing it. There's also the issue of once you delete a submodule... now what? Git won't automatically remove them from other repositories when the change gets pulled. The folder will show up as untracked. So far the current paradigm with git submodules is git is very "hands off" and leaves as much as possible to you. I think we would have to see a change in thought consistently around how to approach submodules before git implements anything of this sort. -- 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