{"thread":{"id":"56749","subject":"Git submodule remove","startedAt":"2021-10-21T17:25:40Z","lastAt":"2021-10-24T20:46:49Z","messageCount":15,"participants":["Kalyan Sriram","brian m. carlson","Junio C Hamano","Matheus Tavares","Ævar Arnfjörð Bjarmason","Randall S. Becker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"439256","messageId":"0101017ca3e30c39-f111f739-4db7-4c1e-aff2-3ee50f546591-000000@us-west-2.amazonses.com","threadId":"56749","inReplyTo":null,"subject":"Git submodule remove","fromName":"Kalyan Sriram","fromEmail":"kalyan@coderkalyan.com","sentAt":"2021-10-21T17:25:38Z","receivedAt":"2021-10-21T17:25:40Z","isPatch":false,"sender":{"key":"kalyan@coderkalyan.com","avatar":null},"body":"Hello,\n\nI was curious why git-submodule does not have an `rm` command. Currently\nI have to manually delete it from .gitmodules, .git/config,\n.git/modules/, etc. See [0].\n\nI'd like to contribute my first patch to this project by adding this\nfeature, but wanted to check first with the community if there's any\nparticular reason it was chosen not to not be implemented, or if it's\nsimply that nobody has gotten around to it - it seems to be a relatively\ncommon feature someone might want.\n\nAnyway, please let me know if this is something that would be accepted,\nor if anyone has any comments or suggestions.\n\nThanks!\nKalyan\n\n[0] https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial#Removal\n"},{"id":"439289","messageId":"YXHdaQ98GJiFj0OK@camp.crustytoothpaste.net","threadId":"56749","inReplyTo":"0101017ca3e30c39-f111f739-4db7-4c1e-aff2-3ee50f546591-000000@us-west-2.amazonses.com","subject":"Re: Git submodule remove","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-10-21T21:36:41Z","receivedAt":"2021-10-21T21:36:48Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n> Hello,\n> \n> I was curious why git-submodule does not have an `rm` command. Currently\n> I have to manually delete it from .gitmodules, .git/config,\n> .git/modules/, etc. See [0].\n> \n> I'd like to contribute my first patch to this project by adding this\n> feature, but wanted to check first with the community if there's any\n> particular reason it was chosen not to not be implemented, or if it's\n> simply that nobody has gotten around to it - it seems to be a relatively\n> common feature someone might want.\n> \n> Anyway, please let me know if this is something that would be accepted,\n> or if anyone has any comments or suggestions.\n\nI think the reason it hasn't been implemented is that nobody's gotten\naround to it yet. I certainly would find this useful and have wanted\nthe same thing myself, so I can't see a reason why the right series\nwouldn't be accepted.\n\nIf someone else knows of a good reason why we haven't done this, I'm all\nears.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"439300","messageId":"xmqqbl3ihu6l.fsf@gitster.g","threadId":"56749","inReplyTo":"YXHdaQ98GJiFj0OK@camp.crustytoothpaste.net","subject":"Re: Git submodule remove","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-21T22:47:14Z","receivedAt":"2021-10-21T22:47:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n>> Hello,\n>> \n>> I was curious why git-submodule does not have an `rm` command. Currently\n>> I have to manually delete it from .gitmodules, .git/config,\n>> .git/modules/, etc. See [0].\n>> \n>> I'd like to contribute my first patch to this project by adding this\n>> feature, but wanted to check first with the community if there's any\n>> particular reason it was chosen not to not be implemented, or if it's\n>> simply that nobody has gotten around to it - it seems to be a relatively\n>> common feature someone might want.\n>> \n>> Anyway, please let me know if this is something that would be accepted,\n>> or if anyone has any comments or suggestions.\n>\n> I think the reason it hasn't been implemented is that nobody's gotten\n> around to it yet. I certainly would find this useful and have wanted\n> the same thing myself, so I can't see a reason why the right series\n> wouldn't be accepted.\n\nI tend to agree that nobody felt the need strongly enough. Code\ntends to accumulate without ever getting removed, and removal of a\nfile, removal of a directory, or removal of a submodule is a much\nrarer event compared to other changes people would need to make.\nAdding such a feature would have been much more work for those who\nfaced such a rare occasion to want to use it than just doing it by\nhand and committing the result.\n\nI'd imagine that the happy-case implementation should be fairly\nstraight-forward. You would:\n\n - ensure that the submodule is \"absorbed\" already;\n\n - run \"git rm -f\" the submodule to remove the gitlink from the index\n and remove the directory from the working tree; and\n\n - remove the .gitmodules entry for the submodule.\n\nand you'd leave the final \"record the state of the index as a\ncommit\" to the user, simply because the user would want to have\nother changes related to the removal of the submodule in the same\ncommit (like changes to files in the superproject that refer to the\nsubmodule contents or removal of other submodules).\n\nThe hard part is unhappy-cases. There are too many things that can\ngo wrong and you need to handle all the error cases correctly so\nthat you do not leave the user's repository in an uncontrollably\nmessy state.\n\nThanks.\n"},{"id":"439304","messageId":"CAHd-oW5PfygyNsRWGg4_W2pxR_HbePvguKRf-bK9RtY3cuAX9g@mail.gmail.com","threadId":"56749","inReplyTo":"xmqqbl3ihu6l.fsf@gitster.g","subject":"Re: Git submodule remove","fromName":"Matheus Tavares","fromEmail":"matheus.bernardino@usp.br","sentAt":"2021-10-21T23:25:03Z","receivedAt":"2021-10-21T23:25:19Z","isPatch":false,"sender":{"key":"matheus.tavb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701583?v=4"},"body":"On Thu, Oct 21, 2021 at 7:47 PM Junio C Hamano wrote:\n>\n> \"brian m. carlson\" writes:\n>\n> > On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n> >> Hello,\n> >>\n> >> I was curious why git-submodule does not have an `rm` command. Currently\n> >> I have to manually delete it from .gitmodules, .git/config,\n> >> .git/modules/, etc. See [0].\n> >>\n[...]\n> I'd imagine that the happy-case implementation should be fairly\n> straight-forward. You would:\n>\n> - ensure that the submodule is \"absorbed\" already;\n>\n> - run \"git rm -f\" the submodule to remove the gitlink from the index\n> and remove the directory from the working tree; and\n>\n> - remove the .gitmodules entry for the submodule.\n\nI think \"git rm \" already does these three steps, doesn't it?\n"},{"id":"439308","messageId":"xmqqee8egddw.fsf@gitster.g","threadId":"56749","inReplyTo":"CAHd-oW5PfygyNsRWGg4_W2pxR_HbePvguKRf-bK9RtY3cuAX9g@mail.gmail.com","subject":"Re: Git submodule remove","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-21T23:35:23Z","receivedAt":"2021-10-21T23:35:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matheus Tavares writes:\n\n> On Thu, Oct 21, 2021 at 7:47 PM Junio C Hamano wrote:\n>>\n>> \"brian m. carlson\" writes:\n>>\n>> > On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n>> >> Hello,\n>> >>\n>> >> I was curious why git-submodule does not have an `rm` command. Currently\n>> >> I have to manually delete it from .gitmodules, .git/config,\n>> >> .git/modules/, etc. See [0].\n>> >>\n> [...]\n>> I'd imagine that the happy-case implementation should be fairly\n>> straight-forward. You would:\n>>\n>> - ensure that the submodule is \"absorbed\" already;\n>>\n>> - run \"git rm -f\" the submodule to remove the gitlink from the index\n>> and remove the directory from the working tree; and\n>>\n>> - remove the .gitmodules entry for the submodule.\n>\n> I think \"git rm \" already does these three steps, doesn't it?\n\nWow, that is a unnerving layering violation, but I suspect it is too\nlate to fix it. So perhaps \"git submodule rm\" would just become a\nsynonym for \"git rm\"?\n\nThanks.\n"},{"id":"439328","messageId":"0101017ca60e5ffd-9563fafd-86f6-443d-9cbe-e07203caacba-000000@us-west-2.amazonses.com","threadId":"56749","inReplyTo":"xmqqee8egddw.fsf@gitster.g","subject":"Re: Git submodule remove","fromName":"Kalyan Sriram","fromEmail":"kalyan@coderkalyan.com","sentAt":"2021-10-22T03:32:12Z","receivedAt":"2021-10-22T03:32:16Z","isPatch":false,"sender":{"key":"kalyan@coderkalyan.com","avatar":null},"body":"On Thu Oct 21, 2021 at 4:35 PM PDT, Junio C Hamano wrote:\n> Matheus Tavares writes:\n>\n> > On Thu, Oct 21, 2021 at 7:47 PM Junio C Hamano wrote:\n> >>\n> >> \"brian m. carlson\" writes:\n> >>\n> >> > On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n> >> >> Hello,\n> >> >>\n> >> >> I was curious why git-submodule does not have an `rm` command. Currently\n> >> >> I have to manually delete it from .gitmodules, .git/config,\n> >> >> .git/modules/, etc. See [0].\n> >> >>\n> > [...]\n> >> I'd imagine that the happy-case implementation should be fairly\n> >> straight-forward. You would:\n> >>\n> >> - ensure that the submodule is \"absorbed\" already;\n> >>\n> >> - run \"git rm -f\" the submodule to remove the gitlink from the index\n> >> and remove the directory from the working tree; and\n> >>\n> >> - remove the .gitmodules entry for the submodule.\n> >\n> > I think \"git rm \" already does these three steps, doesn't it?\n\nWow, this is a surprise. Looks like this behavior is mentioned in the\nman page but is not very well known.\n> So perhaps \"git submodule rm\" would just become a synonym for \"git rm\"?\n>\n> Thanks.\nAlmost, yeah, but not quite. I ran a couple quick tests to clarify my own\nunderstanding of how submodules work, and found that:\n\n\"git rm\" deletes the submodule directory completely and modifies\n.gitmodules, effectively removing the submodule. However, it leaves the\nentry in .git/config dangling, which is annoying.\n\n\"git submodule deinit\" (which I didn't know existed until I just read the man\npage) deletes all contents of submodule directory, but leaves the \n(empty) submodule directory itself intact. It DOES delete the entry in\n.git/config, but leaves a dangling entry in .gitmodules, so the next\n\"git submodule update --init --recursive\" registers and populates the\nsubmodule again.\n\n>\n> Wow, that is a unnerving layering violation, but I suspect it is too\n> late to fix it. \nI agree, it's probably too late to change the behavior of \"git rm\"\nregarding how it treats submodules. That said, I think the cleanest\nsolution would be to update \"git rm\" to also remove the dangling\n.git/config entry. Then, I could make \"git submodule rm\" a synonym for\n\"git rm\" for clarity. This would probably also involve updating\ndocumentation in multiple locations to make sure everything is\nconsistent, and verifying \"git rm\" doesn't leave anything else about the\nsubmodule dangling. Please let me know if anyone has a better idea for\nanything I listed.\n\nThanks for your input so far, Junio, Matheus, and Brian! If no one has\nany objections, I'll figure out how to make these updates and send a\npatch along.\n\nThanks!\nKalyan\n"},{"id":"439366","messageId":"211022.86lf2ll00x.gmgdl@evledraar.gmail.com","threadId":"56749","inReplyTo":"xmqqee8egddw.fsf@gitster.g","subject":"Re: Git submodule remove","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-10-22T12:12:11Z","receivedAt":"2021-10-22T12:25:10Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Oct 21 2021, Junio C Hamano wrote:\n\n> Matheus Tavares writes:\n>\n>> On Thu, Oct 21, 2021 at 7:47 PM Junio C Hamano wrote:\n>>>\n>>> \"brian m. carlson\" writes:\n>>>\n>>> > On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n>>> >> Hello,\n>>> >>\n>>> >> I was curious why git-submodule does not have an `rm` command. Currently\n>>> >> I have to manually delete it from .gitmodules, .git/config,\n>>> >> .git/modules/, etc. See [0].\n>>> >>\n>> [...]\n>>> I'd imagine that the happy-case implementation should be fairly\n>>> straight-forward. You would:\n>>>\n>>> - ensure that the submodule is \"absorbed\" already;\n>>>\n>>> - run \"git rm -f\" the submodule to remove the gitlink from the index\n>>> and remove the directory from the working tree; and\n>>>\n>>> - remove the .gitmodules entry for the submodule.\n>>\n>> I think \"git rm \" already does these three steps, doesn't it?\n>\n> Wow, that is a unnerving layering violation, but I suspect it is too\n> late to fix it. So perhaps \"git submodule rm\" would just become a\n> synonym for \"git rm\"?\n>\n> Thanks.\n\nWhy would it be a good thing to change it even if we could? We added\nthat section with \"git submodule add\", it makes sense to have it removed\non \"git init\". The user could have added it manually, but the same goes\nfor manually added config that \"git remote remove\" would remove.\n\nIf anything I think it would make sense to extend this behavior. E.g. if\nwe \"git rm\" a and notice that the was the only thing that\nmatched a given entry in .gitignore we should remove that entry.\n\nOr e.g. warn if we notice that the non-ext name of the removed file is\nthe only thing matching non-ext-versions of .gitignore, i.e. to catch\nthe common case of removing a \"foo.c\", but leaving a \"foo.o\" gitignore\nentry behind.\n\nSee 95c16418f03 (rm: delete .gitmodules entry of submodules removed from\nthe work tree, 2013-08-06) for the commit that gave \"git rm\" these\nsmarts.\n\nI used to think that \"git rm\" was a bad layering violation, i.e. what's\nthe point of it over:\n\n rm foo\n git add foo\n\nAnd in the early days having it at all is IMO one of the things that\nconfused a lot of users about git's data model, i.e. they'd re-do their\nmoves or removals with the \"git mv\" or \"git rm\", thinking the SCM cared\nabout being informed of things like that.\n\nBut those commands are worthwhile, because they interact nicely with\nother native git features, pathspecs, .gitmodules etc.\n\nFWIW I think one thing that might make the \"git submodule\" interface\nless confusing is to go in the opposite direction, not to add a \"git\nsubmodule rm\" or whatever, but think about whether we need something\nlike \"git submodule add\" at all, i.e. shouldn't that ideally just be\nsome special-case of \"git add\" or \"git clone\"?\n\nI.e. Either you \"git clone\" to the working tree and it Just Works (adds\n.gitmodules and all), or \"git add\" on a directory with a .git dir in it\nwill (perhps after asking) shimmy up the relevant submodule scaffolding.\n"},{"id":"439369","messageId":"016801d7c74b$64bb9a90$2e32cfb0$@nexbridge.com","threadId":"56749","inReplyTo":"xmqqbl3ihu6l.fsf@gitster.g","subject":"RE: Git submodule remove","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-10-22T13:47:39Z","receivedAt":"2021-10-22T13:48:04Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 21, 2021 6:47 PM, Junio C Hamano wrote:\n>To: brian m. carlson \n>Cc: Kalyan Sriram ; git@vger.kernel.org\n>Subject: Re: Git submodule remove\n>\n>\"brian m. carlson\" writes:\n>\n>> On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n>>> Hello,\n>>>\n>>> I was curious why git-submodule does not have an `rm` command.\n>>> Currently I have to manually delete it from .gitmodules, .git/config,\n>>> .git/modules/, etc. See [0].\n>>>\n>>> I'd like to contribute my first patch to this project by adding this\n>>> feature, but wanted to check first with the community if there's any\n>>> particular reason it was chosen not to not be implemented, or if it's\n>>> simply that nobody has gotten around to it - it seems to be a\n>>> relatively common feature someone might want.\n>>>\n>>> Anyway, please let me know if this is something that would be\n>>> accepted, or if anyone has any comments or suggestions.\n>>\n>> I think the reason it hasn't been implemented is that nobody's gotten\n>> around to it yet. I certainly would find this useful and have wanted\n>> the same thing myself, so I can't see a reason why the right series\n>> wouldn't be accepted.\n>\n>I tend to agree that nobody felt the need strongly enough. Code tends to accumulate without ever getting removed, and removal of a\nfile,\n>removal of a directory, or removal of a submodule is a much rarer event compared to other changes people would need to make.\n>Adding such a feature would have been much more work for those who faced such a rare occasion to want to use it than just doing it\nby\n>hand and committing the result.\n>\n>I'd imagine that the happy-case implementation should be fairly straight-forward. You would:\n>\n> - ensure that the submodule is \"absorbed\" already;\n>\n> - run \"git rm -f\" the submodule to remove the gitlink from the index\n> and remove the directory from the working tree; and\n>\n> - remove the .gitmodules entry for the submodule.\n>\n>and you'd leave the final \"record the state of the index as a commit\" to the user, simply because the user would want to have other\n>changes related to the removal of the submodule in the same commit (like changes to files in the superproject that refer to the\n>submodule contents or removal of other submodules).\n>\n>The hard part is unhappy-cases. There are too many things that can go wrong and you need to handle all the error cases correctly\nso that\n>you do not leave the user's repository in an uncontrollably messy state.\n\nJust my rambling:\n\nThe really unhappy place is when a user deletes the upstream submodule repo itself after not seeing it in main any longer during\nsome cleanup adventure, then someone else tries to check out an older commit that references the submodule. This particular unhappy\nplace seems a whole lot like 'git branch -d' vs '-D', where it might be good not to allow the submodule rm if it is referenced in a\ncommit (insert acceptable criteria for not forcing it here, which probably doesn't exist). A prune-like operation, as with workspace\nprune might be a little safer - but not much.\n\n-Randall\n\n"},{"id":"439396","messageId":"0101017ca921a6a0-96383fe2-4d73-47cb-83f7-4152b2c6ed7e-000000@us-west-2.amazonses.com","threadId":"56749","inReplyTo":"016801d7c74b$64bb9a90$2e32cfb0$@nexbridge.com","subject":"RE: Git submodule remove","fromName":"Kalyan Sriram","fromEmail":"kalyan@coderkalyan.com","sentAt":"2021-10-22T17:52:07Z","receivedAt":"2021-10-22T17:52:09Z","isPatch":false,"sender":{"key":"kalyan@coderkalyan.com","avatar":null},"body":"On Fri Oct 22, 2021 at 6:47 AM PDT, Randall S. Becker wrote:\n> On October 21, 2021 6:47 PM, Junio C Hamano wrote:\n> >To: brian m. carlson \n> >Cc: Kalyan Sriram ; git@vger.kernel.org\n> >Subject: Re: Git submodule remove\n> >\n> >\"brian m. carlson\" writes:\n> >\n> >> On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n> >>> Hello,\n> >>>\n> >>> I was curious why git-submodule does not have an `rm` command.\n> >>> Currently I have to manually delete it from .gitmodules, .git/config,\n> >>> .git/modules/, etc. See [0].\n> >>>\n> >>> I'd like to contribute my first patch to this project by adding this\n> >>> feature, but wanted to check first with the community if there's any\n> >>> particular reason it was chosen not to not be implemented, or if it's\n> >>> simply that nobody has gotten around to it - it seems to be a\n> >>> relatively common feature someone might want.\n> >>>\n> >>> Anyway, please let me know if this is something that would be\n> >>> accepted, or if anyone has any comments or suggestions.\n> >>\n> >> I think the reason it hasn't been implemented is that nobody's gotten\n> >> around to it yet. I certainly would find this useful and have wanted\n> >> the same thing myself, so I can't see a reason why the right series\n> >> wouldn't be accepted.\n> >\n> >I tend to agree that nobody felt the need strongly enough. Code tends to accumulate without ever getting removed, and removal of a\n> file,\n> >removal of a directory, or removal of a submodule is a much rarer event compared to other changes people would need to make.\n> >Adding such a feature would have been much more work for those who faced such a rare occasion to want to use it than just doing it\n> by\n> >hand and committing the result.\n> >\n> >I'd imagine that the happy-case implementation should be fairly straight-forward. You would:\n> >\n> > - ensure that the submodule is \"absorbed\" already;\n> >\n> > - run \"git rm -f\" the submodule to remove the gitlink from the index\n> > and remove the directory from the working tree; and\n> >\n> > - remove the .gitmodules entry for the submodule.\n> >\n> >and you'd leave the final \"record the state of the index as a commit\" to the user, simply because the user would want to have other\n> >changes related to the removal of the submodule in the same commit (like changes to files in the superproject that refer to the\n> >submodule contents or removal of other submodules).\n> >\n> >The hard part is unhappy-cases. There are too many things that can go wrong and you need to handle all the error cases correctly\n> so that\n> >you do not leave the user's repository in an uncontrollably messy state.\n>\n> Just my rambling:\n>\n> The really unhappy place is when a user deletes the upstream submodule\n> repo itself after not seeing it in main any longer during\n> some cleanup adventure, then someone else tries to check out an older\n> commit that references the submodule.\nIMO this seems like a pretty unlikely situation to be in, which doesn't\nwarrant *not* adding this feature. I get the idea, but how commonly do\npeople checkout old commits and play around with them? In any case, this\nseems to be the project maintainer's problem, not git's.\n> This particular unhappy\n> place seems a whole lot like 'git branch -d' vs '-D', where it might be\n> good not to allow the submodule rm if it is referenced in a\n> commit (insert acceptable criteria for not forcing it here, which\n> probably doesn't exist).\nBut wouldn't a submodule always be referenced in a commit? The first\nthing anyone does after adding a submodule, after all, is to commit it\ninto the repository. Later on, you may decide you don't need that\nsubmodule dependency anymore...\n> A prune-like operation, as with workspace\n> prune might be a little safer - but not much.\nSorry, I'm having a hard time understanding. What would this look like, and how\nit would be safer?\n\nThanks!\nKalyan\n"},{"id":"439418","messageId":"01a201d7c785$b9261ee0$2b725ca0$@nexbridge.com","threadId":"56749","inReplyTo":"0101017ca921a6a0-96383fe2-4d73-47cb-83f7-4152b2c6ed7e-000000@us-west-2.amazonses.com","subject":"RE: Git submodule remove","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-10-22T20:45:12Z","receivedAt":"2021-10-22T20:45:35Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 22, 2021 1:52 PM, Kalyan Sriram wrote:\n>To: Randall S. Becker ; 'Junio C Hamano' ; 'brian m. carlson'\n>\n>Cc: git@vger.kernel.org\n>Subject: RE: Git submodule remove\n>\n>On Fri Oct 22, 2021 at 6:47 AM PDT, Randall S. Becker wrote:\n>> On October 21, 2021 6:47 PM, Junio C Hamano wrote:\n>> >To: brian m. carlson \n>> >Cc: Kalyan Sriram ; git@vger.kernel.org\n>> >Subject: Re: Git submodule remove\n>> >\n>> >\"brian m. carlson\" writes:\n>> >\n>> >> On 2021-10-21 at 17:25:38, Kalyan Sriram wrote:\n>> >>> Hello,\n>> >>>\n>> >>> I was curious why git-submodule does not have an `rm` command.\n>> >>> Currently I have to manually delete it from .gitmodules,\n>> >>> .git/config, .git/modules/, etc. See [0].\n>> >>>\n>> >>> I'd like to contribute my first patch to this project by adding\n>> >>> this feature, but wanted to check first with the community if\n>> >>> there's any particular reason it was chosen not to not be\n>> >>> implemented, or if it's simply that nobody has gotten around to it\n>> >>> - it seems to be a relatively common feature someone might want.\n>> >>>\n>> >>> Anyway, please let me know if this is something that would be\n>> >>> accepted, or if anyone has any comments or suggestions.\n>> >>\n>> >> I think the reason it hasn't been implemented is that nobody's\n>> >> gotten around to it yet. I certainly would find this useful and\n>> >> have wanted the same thing myself, so I can't see a reason why the\n>> >> right series wouldn't be accepted.\n>> >\n>> >I tend to agree that nobody felt the need strongly enough. Code\n>> >tends to accumulate without ever getting removed, and removal of a\n>> file,\n>> >removal of a directory, or removal of a submodule is a much rarer event compared to other changes people would need to make.\n>> >Adding such a feature would have been much more work for those who\n>> >faced such a rare occasion to want to use it than just doing it\n>> by\n>> >hand and committing the result.\n>> >\n>> >I'd imagine that the happy-case implementation should be fairly straight-forward. You would:\n>> >\n>> > - ensure that the submodule is \"absorbed\" already;\n>> >\n>> > - run \"git rm -f\" the submodule to remove the gitlink from the index\n>> > and remove the directory from the working tree; and\n>> >\n>> > - remove the .gitmodules entry for the submodule.\n>> >\n>> >and you'd leave the final \"record the state of the index as a commit\"\n>> >to the user, simply because the user would want to have other changes\n>> >related to the removal of the submodule in the same commit (like changes to files in the superproject that refer to the submodule\n>contents or removal of other submodules).\n>> >\n>> >The hard part is unhappy-cases. There are too many things that can\n>> >go wrong and you need to handle all the error cases correctly\n>> so that\n>> >you do not leave the user's repository in an uncontrollably messy state.\n>>\n>> Just my rambling:\n>>\n>> The really unhappy place is when a user deletes the upstream submodule\n>> repo itself after not seeing it in main any longer during some cleanup\n>> adventure, then someone else tries to check out an older commit that\n>> references the submodule.\n>IMO this seems like a pretty unlikely situation to be in, which doesn't warrant *not* adding this feature. I get the idea, but how commonly\n>do people checkout old commits and play around with them? In any case, this seems to be the project maintainer's problem, not git's.\n>> This particular unhappy\n>> place seems a whole lot like 'git branch -d' vs '-D', where it might\n>> be good not to allow the submodule rm if it is referenced in a commit\n>> (insert acceptable criteria for not forcing it here, which probably\n>> doesn't exist).\n>But wouldn't a submodule always be referenced in a commit? The first thing anyone does after adding a submodule, after all, is to\n>commit it into the repository. Later on, you may decide you don't need that submodule dependency anymore...\n>> A prune-like operation, as with workspace prune might be a little\n>> safer - but not much.\n>Sorry, I'm having a hard time understanding. What would this look like, and how it would be safer?\n\nGiven that git is distributed, probably not safer at all (see other responses in the thread). I really don't like the submodule rm concept in the slightest although I appreciate the necessity, but you really really have to want it. A prune operation might be better if a criteria could be specified to define when removing the submodule might be acceptable, at least locally. Suppose:\n\ngit submodule prune --branch=main --after=commitish\n\nwhich could allow the prune if the submodule was not referenced on the main branches before a certain point in history. I don't like it, but it might be an idea worth thinking about.\n\n-Randall\n\n"},{"id":"439420","messageId":"xmqqlf2kep41.fsf@gitster.g","threadId":"56749","inReplyTo":"0101017ca921a6a0-96383fe2-4d73-47cb-83f7-4152b2c6ed7e-000000@us-west-2.amazonses.com","subject":"Re: Git submodule remove","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-22T21:17:18Z","receivedAt":"2021-10-22T21:17:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kalyan Sriram\" writes:\n\n>> The really unhappy place is when a user deletes the upstream submodule\n>> repo itself after not seeing it in main any longer during\n>> some cleanup adventure, then someone else tries to check out an older\n>> commit that references the submodule.\n>\n> IMO this seems like a pretty unlikely situation to be in, which doesn't\n> warrant *not* adding this feature. I get the idea, but how commonly do\n> people checkout old commits and play around with them?\n\nYou MUST be able to go back to old versions. Otherwise, why are we\nworking on a version control system? You may find that in the old\ndays in v1.0 something used to work and in today's code it does not.\nYou would want to bisect and need to be able to go back to v1.0 that\nstill had the submodule you recently removed. And you check where\nin the history since v1.0 the actual breakage happend---it is called\n\"bisection\" and people do that all the time. IOW, it is VERY common.\n\nAnd that is why I said \"submodule rm\" should *not* just \"rm -fr\nsubmodule-dir/\", but ensure that submodule-dir/.git is absorbed (in\n.git/modules/submodule-dir, most likely) before doing so, and then\nthe entry for the submodule should be removed from .gitmodules, but\nI deliberatly did not mention anything about .git/config. The entry\nshould in general _stay_ there, because having an entry for a\nsubmodule in .git/config means you are interested in it (e.g. your\nbuild may require having it, for a commit in the superproject that\nstill had the submodule there). When you are on a commit in the\nsuperproject after the submodule was removed, you may not have\nanything from the submodule materialized in the working tree, but\nwhen you go back in the history, you do still need to be able to\nmaterialize it.\n\n> In any case, this\n> seems to be the project maintainer's problem, not git's.\n\nYou are correct. The remote side removing some repository and\nmaking it unavailable is just as bad as the site going down. \n\nOn your side, you would want to be able to continue working even\nwhen that happens, and not simply removing submodule-dir/.git\ntogether with submodule-dir/ before making sure the submodule is\nabsorbed makes sure you'd have a local copy of the submodule\nrepository available just like you have local copy of the\nsuperproject repository available.\n"},{"id":"439424","messageId":"xmqq8rykeoex.fsf@gitster.g","threadId":"56749","inReplyTo":"211022.86lf2ll00x.gmgdl@evledraar.gmail.com","subject":"Re: Git submodule remove","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-22T21:32:22Z","receivedAt":"2021-10-22T21:32:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Why would it be a good thing to change it even if we could? We added\n> that section with \"git submodule add\", it makes sense to have it removed\n> on \"git init\".\n\n... on \"git submodule rm\", yes. Not \"git rm\". I am not sure what\nyour \"git init\" is your typo for.\n\nThat is primarily because I do not believe the \"git submodule\"'s\nworld view is the _only_ valid porcelain UI for a feature that lets\nyou use another project as if it is one of your subdirectories. So\nwhatever opinionated policy the current \"git submodule\" implements,\nI'd prefer to keep it in \"git submodule\" (and \".gitmodules\", which is\nwhere the data to support \"git submodule\"-style submodule handling\nlives in), not in the lower level \"git add\" and \"git rm\".\n\n> If anything I think it would make sense to extend this behavior. E.g. if\n> we \"git rm\" a and notice that the was the only thing that\n> matched a given entry in .gitignore we should remove that entry.\n\nI think that is a wrong analogy.\n\nIt does not make sense to me to remove \"*.o\" from my .gitignore,\nwhen I do \"git rm vendor-binary.o\". I have \"*.o\" in .gitignore\nbecause I do not want to add .o files produced by compiling my\nsource files, and the \"git rm\" does not change that fact at all.\n\nI unfortunately had to keep track of an opaque vendor-supplied\nbinary, which got replaced recently with a new version, and that is\nwhy I am running \"git rm\" on it. \"git add -f vendor-binary-v2.o\"\nis what I was planning to do next.\n\nI do not want you to mess with my .gitignore; you are assuming too\nmuch on my workflow.\n\n> See 95c16418f03 (rm: delete .gitmodules entry of submodules removed from\n> the work tree, 2013-08-06) for the commit that gave \"git rm\" these\n> smarts.\n\nI know. That is exactly the layering violation I am unhappy about\nbut we came with it too far to remove.\n"},{"id":"439427","messageId":"xmqq4k98en01.fsf@gitster.g","threadId":"56749","inReplyTo":"0101017ca60e5ffd-9563fafd-86f6-443d-9cbe-e07203caacba-000000@us-west-2.amazonses.com","subject":"Re: Git submodule remove","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-22T22:02:54Z","receivedAt":"2021-10-22T22:03:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kalyan Sriram\" writes:\n\n> \"git rm\" deletes the submodule directory completely and modifies\n> .gitmodules, effectively removing the submodule. However, it leaves the\n> entry in .git/config dangling, which is annoying.\n\nThe entry is not dangling. It is there to be used when you go back\nin history.\n\n> \"git submodule deinit\" (which I didn't know existed until I just read the man\n> page) deletes all contents of submodule directory, but leaves the \n> (empty) submodule directory itself intact. It DOES delete the entry in\n> .git/config, but leaves a dangling entry in .gitmodules, so the next\n> \"git submodule update --init --recursive\" registers and populates the\n> submodule again.\n\n\"deinit\" is *not* about remove a submodule. A project can be\nchecked out and used with or without its submodules instantiated,\nand \"git submodule init\" is a way to instantiate it. \"deinit\" is\nits opposite. As far as the history (which has already been\nrecorded in the repository, and the history that will be recorded\nin the repository starting from that state) is concerned, the\nsubmodule is there---it's just that you are not interested in it and\nchose not to check it out.\n\nSo \"git rm\" seems to be doing exactly what \"git submodule rm\" should\nbe doing, nothing more, nothing less.\n"},{"id":"439507","messageId":"0101017cb4026947-7e22d019-674b-4d1c-b229-b10328252341-000000@us-west-2.amazonses.com","threadId":"56749","inReplyTo":"xmqq4k98en01.fsf@gitster.g","subject":"Re: Git submodule remove","fromName":"Kalyan Sriram","fromEmail":"kalyan@coderkalyan.com","sentAt":"2021-10-24T20:33:49Z","receivedAt":"2021-10-24T20:33:51Z","isPatch":false,"sender":{"key":"kalyan@coderkalyan.com","avatar":null},"body":"On Fri Oct 22, 2021 at 3:02 PM PDT, Junio C Hamano wrote:\n> \"Kalyan Sriram\" writes:\n>\n> > \"git rm\" deletes the submodule directory completely and modifies\n> > .gitmodules, effectively removing the submodule. However, it leaves the\n> > entry in .git/config dangling, which is annoying.\n>\n> The entry is not dangling. It is there to be used when you go back\n> in history.\n>\n> > \"git submodule deinit\" (which I didn't know existed until I just read the man\n> > page) deletes all contents of submodule directory, but leaves the \n> > (empty) submodule directory itself intact. It DOES delete the entry in\n> > .git/config, but leaves a dangling entry in .gitmodules, so the next\n> > \"git submodule update --init --recursive\" registers and populates the\n> > submodule again.\n>\n> \"deinit\" is *not* about remove a submodule. A project can be\n> checked out and used with or without its submodules instantiated,\n> and \"git submodule init\" is a way to instantiate it. \"deinit\" is\n> its opposite. As far as the history (which has already been\n> recorded in the repository, and the history that will be recorded\n> in the repository starting from that state) is concerned, the\n> submodule is there---it's just that you are not interested in it and\n> chose not to check it out.\n>\n> So \"git rm\" seems to be doing exactly what \"git submodule rm\" should\n> be doing, nothing more, nothing less.\n\nThat makes sense, thanks for the clarification. So it looks like there\nisn't any work to be done here after all?\n\nWhat are your thoughts about aliasing git submodule rm to git rm? \n\nThanks,\nKalyan\n"},{"id":"439509","messageId":"xmqqo87e40cq.fsf@gitster.g","threadId":"56749","inReplyTo":"0101017cb4026947-7e22d019-674b-4d1c-b229-b10328252341-000000@us-west-2.amazonses.com","subject":"Re: Git submodule remove","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-10-24T20:46:45Z","receivedAt":"2021-10-24T20:46:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kalyan Sriram\" writes:\n\n>> So \"git rm\" seems to be doing exactly what \"git submodule rm\" should\n>> be doing, nothing more, nothing less.\n>\n> That makes sense, thanks for the clarification. So it looks like there\n> isn't any work to be done here after all?\n>\n> What are your thoughts about aliasing git submodule rm to git rm? \n\nIt is unfortunate that \"git rm\" learned these \"extra\" things that\nare integral part of \"submodule removal\" if you believe that the way\n\"submodules\" are handled in the current \"git submodule\"-style design\nis the only thing all Git users must follow.\n\nUnless we plan to eventually make \"git rm\" unlearn these hardcoded\n'git submodule'-way actions it does (like editing the .gitmodules\nfile) and move them to \"git submodule rm\", I do not think it is\nworth the engineering effort to add an alias so that \"git submodule\nrm\" would be a synonym to the current \"git rm\".\n\nThanks.\n"}]}