{"thread":{"id":"20057","subject":"git submodule remove?","startedAt":"2009-07-08T19:41:14Z","lastAt":"2009-07-11T05:27:25Z","messageCount":3,"participants":["Tim Henigan","Raman Gupta","Tim Harper"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"117629","messageId":"32c343770907081241h5925545ah1cb551b31e45ddc0@mail.gmail.com","threadId":"20057","inReplyTo":null,"subject":"git submodule remove?","fromName":"Tim Henigan","fromEmail":"tim.henigan@gmail.com","sentAt":"2009-07-08T19:41:14Z","receivedAt":"2009-07-08T19:41:14Z","isPatch":false,"sender":{"key":"tim.henigan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42022?v=4"},"body":"Hello,\n\nI recently encountered a situation where a user wanted to remove a submodule\nfrom a repository. Searching the mail archive, I found this thread\n[1], but it does\nnot appear that it was ever followed up.\n\nThe Git Submodule Tutorial [2] has instructions for removing submodules, but it\nseems natural to teach git how to \"submodule rm\".\n\nThis change would require git-submodule.sh to:\n 1. Modify the .gitmodules file (remove the entry for the submodule).\n 2. Modify the .git/config file (remove the entry for the submodule).\n 3. Delete the newly untracked files.\n\nAnother option to consider would be a \"submodule rm --cached\" option which would\nkeep the newly untracked files. However, with this option, I believe\nit should still\ndescend into the submodule directory to remove the leftover submodule\n\".git\" folder.\n\nIs there another way of doing this? If not, does this sound like a\nreasonable change?\n\nThanks,\nTim Henigan\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/101610/match=submodule+remove\n[2] http://git.or.cz/gitwiki/GitSubmoduleTutorial\n"},{"id":"117638","messageId":"4A55157C.7020103@fastmail.fm","threadId":"20057","inReplyTo":"32c343770907081241h5925545ah1cb551b31e45ddc0@mail.gmail.com","subject":"Re: git submodule remove?","fromName":"Raman Gupta","fromEmail":"rocketraman@fastmail.fm","sentAt":"2009-07-08T21:54:04Z","receivedAt":"2009-07-08T21:54:04Z","isPatch":false,"sender":{"key":"rocketraman@fastmail.fm","avatar":null},"body":"Tim Henigan wrote:\n> The Git Submodule Tutorial [2] has instructions for removing submodules, but it\n> seems natural to teach git how to \"submodule rm\".\n\nI'd like to see this as well.\n\n> This change would require git-submodule.sh to:\n> 1. Modify the .gitmodules file (remove the entry for the submodule).\n> 2. Modify the .git/config file (remove the entry for the submodule).\n> 3. Delete the newly untracked files.\n\nI'm not sure it should be removed from .git/config, and the untracked\nfiles, automatically. If the module is only being removed on one\nbranch, then switching back to another branch will require the module\nto be initialized again. Of course, then the user has to deal with\nuntracked files and to remember to prune entries from .git/config once\nno more branches refer to them.\n\nThis is also a problem when renaming modules -- I always end up having\nat least two entries in .git/config -- one for the branches using the\nold name and one for the branches using the new name.\n\nPerhaps one way to refactor submodule support in .git/config would be\nto allow .git/config to specify search/replace expressions (simple or\nregex-based) that would apply to the entries in .gitmodules. Most of\nthe time, a few simple expressions should be sufficient to cover all\nof the necessary local settings.\n\nAnother possible useful change/addition would be to move the submodule\nfiles in and out of the superproject (perhaps to/from a holding area\nin superproject/.git) as the user switches their working copy between\nbranches that contain or do not contain specific submodules.\n\nCheers,\nRaman Gupta\n"},{"id":"117815","messageId":"e1a5e9a00907102227y4ea2b1f6y2e9882afd726a4eb@mail.gmail.com","threadId":"20057","inReplyTo":"32c343770907081241h5925545ah1cb551b31e45ddc0@mail.gmail.com","subject":"Re: git submodule remove?","fromName":"Tim Harper","fromEmail":"timcharper@gmail.com","sentAt":"2009-07-11T05:27:25Z","receivedAt":"2009-07-11T05:27:25Z","isPatch":false,"sender":{"key":"timcharper@gmail.com","avatar":"https://gravatar.com/avatar/1a2e0c06c7862ff065ee6b1d53195333a5a0577c040ecb2856a150d8e0b00ecd?d=mp&s=160"},"body":"On Wed, Jul 8, 2009 at 1:41 PM, Tim Henigan wrote:\n> Hello,\n>\n> I recently encountered a situation where a user wanted to remove a submodule\n> from a repository.  Searching the mail archive, I found this thread\n> [1], but it does\n> not appear that it was ever followed up.\n>\n> The Git Submodule Tutorial [2] has instructions for removing submodules, but it\n> seems natural to teach git how to \"submodule rm\".\n>\n> This change would require git-submodule.sh to:\n>    1. Modify the .gitmodules file (remove the entry for the submodule).\n>    2. Modify the .git/config file (remove the entry for the submodule).\n>    3. Delete the newly untracked files.\n>\n\nSubmodules are tracked by the tree. You'll need to 'rm -rf' the\nsubmodule, and then 'git rm' the folder to remove it.\n\n> Another option to consider would be a \"submodule rm --cached\" option which would\n> keep the newly untracked files.  However, with this option, I believe\n> it should still\n> descend into the submodule directory to remove the leftover submodule\n> \".git\" folder.\n>\n> Is there another way of doing this?  If not, does this sound like a\n> reasonable change?\n\nI can think of the only opposition being how blatantly dangerous it\nwould be. You're creating a command that will nuke the whole\nrepository, along with any unpushed changes. There's potential there\nfor someone to seriously injure themselves without realizing it.\n\nThere's also the issue of once you delete a submodule... now what?\nGit won't automatically remove them from other repositories when the\nchange gets pulled. The folder will show up as untracked. So far the\ncurrent paradigm with git submodules is git is very \"hands off\" and\nleaves as much as possible to you. I think we would have to see a\nchange in thought consistently around how to approach submodules\nbefore git implements anything of this sort.\n"}]}