{"thread":{"id":"38822","subject":"[RFC] git submodule purge","startedAt":"2015-03-16T13:44:07Z","lastAt":"2015-03-26T21:48:22Z","messageCount":11,"participants":["Patrick Steinhardt","Junio C Hamano","Jonathan Nieder","Fredrik Gustafsson","Jens Lehmann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"257781","messageId":"20150316134407.GA31794@pks-tp.elego.de","threadId":"38822","inReplyTo":null,"subject":"[RFC] git submodule purge","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-03-16T13:44:07Z","receivedAt":"2015-03-16T13:44:07Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"Hi,\n\nThis proposal is just for discussion. If there is any interest I\nwill implement the feature and send some patches.\n\n\nCurrently it is hard to properly remove submodules. That is when\na submodule is deinitialized and removed from a repository the\ndirectory '.git/modules/' will still be present and\nthere is no way to remove it despite manually calling `rm` on it.\nI think there should be a command that is able to remove those\ndangling repositories if the following conditions are met:\n\n- the submodule should not be initialized\n\n- the submodule should not have an entry in .gitmodules in the\n currently checked out revision\n\n- the submodule should not contain any commits that are not\n upstream\n\n- the submodule should not contain other submodules that do not\n meet those conditions\n\nThis would ensure that it is hard to loose any commits that may\nbe of interest. In the case that the user knows what he is doing\nwe may provide a '--force' switch to override those checks.\n\nWhat is problematic, though, is when there are multiple branches\nunder active development where one branch contains a submodule\nand another one does not. Given the checks listed above, though,\nan accidentally removed submodule repository should not prove\nproblematic as it should be possible to easily re-clone it. It\nmight just be cumbersome if the user accidentally removes a\nsubmodule and has to re-initialize it after switching branches.\n\nRegarding behavior of the command I thought about something like\n`git submodule purge (||-a)` where 'SM_NAME'\nwould remove the given submodule, 'DIRECTORY' would remove all\nsubmodules under a certain directory and '-a' would remove all\nsubmodules that are currently inactive. It might be useful to\nprovide a '--dry-run' switch that lists all submodules that would\nbe removed without actually removing them.\n\nSome questions that arise here:\n\n- should those actions be recursive? E.g. if a submodule contains\n submodules itself, should those be deleted (after the\n conditions are met), as well?\n\n- should the user be asked for consent for every submodule that\n is about to be deleted or do we assume that he knows what he is\n doing?\n\n\nSome feedback on this would be appreciated.\n\nRegards\nPatrick\n"},{"id":"257791","messageId":"xmqqmw3drl7s.fsf@gitster.dls.corp.google.com","threadId":"38822","inReplyTo":"20150316134407.GA31794@pks-tp.elego.de","subject":"Re: [RFC] git submodule purge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-03-16T15:55:03Z","receivedAt":"2015-03-16T15:55:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt writes:\n\n> I think there should be a command that is able to remove those\n> dangling repositories if the following conditions are met:\n>\n> - the submodule should not be initialized\n>\n> - the submodule should not have an entry in .gitmodules in the\n> currently checked out revision\n>\n> - the submodule should not contain any commits that are not\n> upstream\n>\n> - the submodule should not contain other submodules that do not\n> meet those conditions\n\nI do not have a strong opinion on whether it is a good idea to make\nit possible to remove the .git/modules/*, but should it be a\nseparate subcommand, or should it be an option to the 'deinit'\nsubcommand?\n\nAlso, how would you apply the safety to a repository without\n\"upstream\", i.e. the authoritative copy?\n"},{"id":"257816","messageId":"20150316200353.GB5186@google.com","threadId":"38822","inReplyTo":"20150316134407.GA31794@pks-tp.elego.de","subject":"Re: [RFC] git submodule purge","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2015-03-16T20:03:53Z","receivedAt":"2015-03-16T20:03:53Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: Jens and Heiko, submodule experts)\nHi,\n\nPatrick Steinhardt wrote:\n\n> This proposal is just for discussion. If there is any interest I\n> will implement the feature and send some patches.\n>\n> Currently it is hard to properly remove submodules. That is when\n> a submodule is deinitialized and removed from a repository the\n> directory '.git/modules/' will still be present and\n> there is no way to remove it despite manually calling `rm` on it.\n> I think there should be a command that is able to remove those\n> dangling repositories if the following conditions are met:\n>\n> - the submodule should not be initialized\n>\n> - the submodule should not have an entry in .gitmodules in the\n> currently checked out revision\n>\n> - the submodule should not contain any commits that are not\n> upstream\n>\n> - the submodule should not contain other submodules that do not\n> meet those conditions\n>\n> This would ensure that it is hard to loose any commits that may\n> be of interest. In the case that the user knows what he is doing\n> we may provide a '--force' switch to override those checks.\n\nThose conditions look simultaneously too strong and too weak. ;-)\n\nIn principle, it should be safe to remove .git/modules/ as\nlong as\n\n (1) it (and its submodules, sub-sub-modules, etc) doesn't have any\n un-pushed local commits.\n\n (2) it is not being referred to by a .git file in the work tree of\n the parent repository.\n\nCondition (1) can be relaxed if the user knows what they are losing\nand is okay with that. Condition (2) can be avoided by removing\n(de-initing) the copy of that submodule in the worktree at the same\ntime.\n\nThe functionality sounds like a useful thing to have, whether as an\noption to 'git submodule deinit' or as a new subcommand. In the long\nterm I would like it to be possible to do everything 'git submodule'\ncan do using normal git commands instead of that specialized\ninterface. What command do you think this would eventually belong in?\n(An option to \"git gc\", maybe?)\n\nThanks,\nJonathan\n"},{"id":"257844","messageId":"20150317075636.GA354@pks-pc","threadId":"38822","inReplyTo":"20150316200353.GB5186@google.com","subject":"Re: [RFC] git submodule purge","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-03-17T07:56:36Z","receivedAt":"2015-03-17T07:56:36Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote:\n> (+cc: Jens and Heiko, submodule experts)\n> Hi,\n> \n> Patrick Steinhardt wrote:\n> \n> > This proposal is just for discussion. If there is any interest I\n> > will implement the feature and send some patches.\n> >\n> > Currently it is hard to properly remove submodules. That is when\n> > a submodule is deinitialized and removed from a repository the\n> > directory '.git/modules/' will still be present and\n> > there is no way to remove it despite manually calling `rm` on it.\n> > I think there should be a command that is able to remove those\n> > dangling repositories if the following conditions are met:\n> >\n> > - the submodule should not be initialized\n> >\n> > - the submodule should not have an entry in .gitmodules in the\n> > currently checked out revision\n> >\n> > - the submodule should not contain any commits that are not\n> > upstream\n> >\n> > - the submodule should not contain other submodules that do not\n> > meet those conditions\n> >\n> > This would ensure that it is hard to loose any commits that may\n> > be of interest. In the case that the user knows what he is doing\n> > we may provide a '--force' switch to override those checks.\n> \n> Those conditions look simultaneously too strong and too weak. ;-)\n> \n> In principle, it should be safe to remove .git/modules/ as\n> long as\n> \n> (1) it (and its submodules, sub-sub-modules, etc) doesn't have any\n> un-pushed local commits.\n> \n> (2) it is not being referred to by a .git file in the work tree of\n> the parent repository.\n> \n> Condition (1) can be relaxed if the user knows what they are losing\n> and is okay with that. Condition (2) can be avoided by removing\n> (de-initing) the copy of that submodule in the worktree at the same\n> time.\n> \n> The functionality sounds like a useful thing to have, whether as an\n> option to 'git submodule deinit' or as a new subcommand. In the long\n> term I would like it to be possible to do everything 'git submodule'\n> can do using normal git commands instead of that specialized\n> interface. What command do you think this would eventually belong in?\n> (An option to \"git gc\", maybe?)\n> \n> Thanks,\n> Jonathan\n\nThanks for your feedback.\n\nConsidering that purging the submodule is tightly coupled with\nde-initializing it, it might make sense to provide this\nfunctionality as part of `git submodule deinit`. Maybe something\nlike `git submodule deinit --purge` would work for the user.\nProblem is if the user first removes the submodule and does not\nfirst deinitialize it he is not able to purge the repository\nafterwards as deinit will complain about the submodule not being\nmatched anymore. We could just make `deinit --purge` work with\nremoved submodules, but that does not feel very natural to me.\n\n`git gc` feels saner in that regard, but I don't think it would\nbe easy to spot for users as this command is in general not used\nvery frequently by them. One could argue though that it does not\nneed to be discoverable.\n\nRegards\nPatrick\n"},{"id":"257845","messageId":"20150317081826.GB354@pks-pc","threadId":"38822","inReplyTo":"xmqqmw3drl7s.fsf@gitster.dls.corp.google.com","subject":"Re: [RFC] git submodule purge","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-03-17T08:18:26Z","receivedAt":"2015-03-17T08:18:26Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Mar 16, 2015 at 08:55:03AM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt writes:\n> \n> > I think there should be a command that is able to remove those\n> > dangling repositories if the following conditions are met:\n> >\n> > - the submodule should not be initialized\n> >\n> > - the submodule should not have an entry in .gitmodules in the\n> > currently checked out revision\n> >\n> > - the submodule should not contain any commits that are not\n> > upstream\n> >\n> > - the submodule should not contain other submodules that do not\n> > meet those conditions\n> \n> I do not have a strong opinion on whether it is a good idea to make\n> it possible to remove the .git/modules/*, but should it be a\n> separate subcommand, or should it be an option to the 'deinit'\n> subcommand?\n\nSee my response to Jonathan.\n\n> Also, how would you apply the safety to a repository without\n> \"upstream\", i.e. the authoritative copy?\n\nIs it even possible to create a new submodule without any\nupstream repository? At least `git submodule init` does not work\nwithout a corresponding entry in .gitmodules which the user would\nhave needed to create himself manually. In this case one _could_\nassume that the user knows what he is doing and expect him not to\ncall `submodule purge` (or whatever the command will be called)\non the authoritative copy. Other than that I've got no idea how\nto assure safety.\n\nRegards\nPatrick\n"},{"id":"257846","messageId":"20150317082556.GI3766@paksenarrion.iveqy.com","threadId":"38822","inReplyTo":"20150317081826.GB354@pks-pc","subject":"Re: [RFC] git submodule purge","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2015-03-17T08:25:56Z","receivedAt":"2015-03-17T08:25:56Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Tue, Mar 17, 2015 at 09:18:26AM +0100, Patrick Steinhardt wrote:\n> Is it even possible to create a new submodule without any\n> upstream repository? At least `git submodule init` does not work\n> without a corresponding entry in .gitmodules which the user would\n> have needed to create himself manually. In this case one _could_\n> assume that the user knows what he is doing and expect him not to\n> call `submodule purge` (or whatever the command will be called)\n> on the authoritative copy. Other than that I've got no idea how\n> to assure safety.\n\nLook at git/t/t7400-submodule-basic.sh for example at the test starting\nat line 84 on how to add a submodule without any upstream.\n\nGit has already a disadvantage against other SCM (like mercurial)\nbecause it's \"too easy to loose data with git\". Meaning that we purge\nunrefered commits. (Yes this is up to debate if this is good or bad, but\nhere's not the place).\n\nI think we should be very carefully with adding commands that\npermanently removes data. They should be really well crafted so that\nthere's no way to do this by mistake.\n\n-- \nFredrik Gustafsson\n\nphone: +46 733-608274\ne-mail: iveqy@iveqy.com\nwebsite: http://www.iveqy.com\n"},{"id":"258386","messageId":"5510866B.40501@web.de","threadId":"38822","inReplyTo":"20150317075636.GA354@pks-pc","subject":"Re: [RFC] git submodule purge","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2015-03-23T21:32:27Z","receivedAt":"2015-03-23T21:32:27Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:\n> On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote:\n>> (+cc: Jens and Heiko, submodule experts)\n>> Hi,\n>>\n>> Patrick Steinhardt wrote:\n>>\n>>> This proposal is just for discussion. If there is any interest I\n>>> will implement the feature and send some patches.\n>>>\n>>> Currently it is hard to properly remove submodules. That is when\n>>> a submodule is deinitialized and removed from a repository the\n>>> directory '.git/modules/' will still be present and\n>>> there is no way to remove it despite manually calling `rm` on it.\n>>> I think there should be a command that is able to remove those\n>>> dangling repositories if the following conditions are met:\n>>>\n>>> - the submodule should not be initialized\n>>>\n>>> - the submodule should not have an entry in .gitmodules in the\n>>> currently checked out revision\n>>>\n>>> - the submodule should not contain any commits that are not\n>>> upstream\n>>>\n>>> - the submodule should not contain other submodules that do not\n>>> meet those conditions\n>>>\n>>> This would ensure that it is hard to loose any commits that may\n>>> be of interest. In the case that the user knows what he is doing\n>>> we may provide a '--force' switch to override those checks.\n>>\n>> Those conditions look simultaneously too strong and too weak. ;-)\n>>\n>> In principle, it should be safe to remove .git/modules/ as\n>> long as\n>>\n>> (1) it (and its submodules, sub-sub-modules, etc) doesn't have any\n>> un-pushed local commits.\n>>\n>> (2) it is not being referred to by a .git file in the work tree of\n>> the parent repository.\n>>\n>> Condition (1) can be relaxed if the user knows what they are losing\n>> and is okay with that. Condition (2) can be avoided by removing\n>> (de-initing) the copy of that submodule in the worktree at the same\n>> time.\n>>\n>> The functionality sounds like a useful thing to have, whether as an\n>> option to 'git submodule deinit' or as a new subcommand. In the long\n>> term I would like it to be possible to do everything 'git submodule'\n>> can do using normal git commands instead of that specialized\n>> interface. What command do you think this would eventually belong in?\n>> (An option to \"git gc\", maybe?)\n>>\n>> Thanks,\n>> Jonathan\n>\n> Thanks for your feedback.\n>\n> Considering that purging the submodule is tightly coupled with\n> de-initializing it, it might make sense to provide this\n> functionality as part of `git submodule deinit`. Maybe something\n> like `git submodule deinit --purge` would work for the user.\n> Problem is if the user first removes the submodule and does not\n> first deinitialize it he is not able to purge the repository\n> afterwards as deinit will complain about the submodule not being\n> matched anymore. We could just make `deinit --purge` work with\n> removed submodules, but that does not feel very natural to me.\n\nHmm, cmd_deinit() seems to cope with submodules removed by the\nuser just fine (as long as they are still present in the index).\nTo me it feels natural to extend deinit to remove the repo from\n.git/modules too when --purge is given (as long as no unpushed\ncommits are present or -f is given).\n\n> `git gc` feels saner in that regard, but I don't think it would\n> be easy to spot for users as this command is in general not used\n> very frequently by them. One could argue though that it does not\n> need to be discoverable.\n\nThe error message of \"git submodule deinit --purge\" for a\nsubmodule that isn't recorded in the index anymore could point\nthe user to the appropriate gc command. But how do we tell gc\nwhich submodule it should purge? \"--purge=\"\nmaybe?\n"},{"id":"258497","messageId":"20150325090631.GA370@pks-pc.localdomain","threadId":"38822","inReplyTo":"5510866B.40501@web.de","subject":"Re: [RFC] git submodule purge","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-03-25T09:06:31Z","receivedAt":"2015-03-25T09:06:31Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote:\n> Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:\n> > On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote:\n> >> (+cc: Jens and Heiko, submodule experts)\n> >> Hi,\n> >>\n> >> Patrick Steinhardt wrote:\n> >>\n> >>> This proposal is just for discussion. If there is any interest I\n> >>> will implement the feature and send some patches.\n> >>>\n> >>> Currently it is hard to properly remove submodules. That is when\n> >>> a submodule is deinitialized and removed from a repository the\n> >>> directory '.git/modules/' will still be present and\n> >>> there is no way to remove it despite manually calling `rm` on it.\n> >>> I think there should be a command that is able to remove those\n> >>> dangling repositories if the following conditions are met:\n> >>>\n> >>> - the submodule should not be initialized\n> >>>\n> >>> - the submodule should not have an entry in .gitmodules in the\n> >>> currently checked out revision\n> >>>\n> >>> - the submodule should not contain any commits that are not\n> >>> upstream\n> >>>\n> >>> - the submodule should not contain other submodules that do not\n> >>> meet those conditions\n> >>>\n> >>> This would ensure that it is hard to loose any commits that may\n> >>> be of interest. In the case that the user knows what he is doing\n> >>> we may provide a '--force' switch to override those checks.\n> >>\n> >> Those conditions look simultaneously too strong and too weak. ;-)\n> >>\n> >> In principle, it should be safe to remove .git/modules/ as\n> >> long as\n> >>\n> >> (1) it (and its submodules, sub-sub-modules, etc) doesn't have any\n> >> un-pushed local commits.\n> >>\n> >> (2) it is not being referred to by a .git file in the work tree of\n> >> the parent repository.\n> >>\n> >> Condition (1) can be relaxed if the user knows what they are losing\n> >> and is okay with that. Condition (2) can be avoided by removing\n> >> (de-initing) the copy of that submodule in the worktree at the same\n> >> time.\n> >>\n> >> The functionality sounds like a useful thing to have, whether as an\n> >> option to 'git submodule deinit' or as a new subcommand. In the long\n> >> term I would like it to be possible to do everything 'git submodule'\n> >> can do using normal git commands instead of that specialized\n> >> interface. What command do you think this would eventually belong in?\n> >> (An option to \"git gc\", maybe?)\n> >>\n> >> Thanks,\n> >> Jonathan\n> >\n> > Thanks for your feedback.\n> >\n> > Considering that purging the submodule is tightly coupled with\n> > de-initializing it, it might make sense to provide this\n> > functionality as part of `git submodule deinit`. Maybe something\n> > like `git submodule deinit --purge` would work for the user.\n> > Problem is if the user first removes the submodule and does not\n> > first deinitialize it he is not able to purge the repository\n> > afterwards as deinit will complain about the submodule not being\n> > matched anymore. We could just make `deinit --purge` work with\n> > removed submodules, but that does not feel very natural to me.\n> \n> Hmm, cmd_deinit() seems to cope with submodules removed by the\n> user just fine (as long as they are still present in the index).\n> To me it feels natural to extend deinit to remove the repo from\n> .git/modules too when --purge is given (as long as no unpushed\n> commits are present or -f is given).\n> \n> > `git gc` feels saner in that regard, but I don't think it would\n> > be easy to spot for users as this command is in general not used\n> > very frequently by them. One could argue though that it does not\n> > need to be discoverable.\n> \n> The error message of \"git submodule deinit --purge\" for a\n> submodule that isn't recorded in the index anymore could point\n> the user to the appropriate gc command. But how do we tell gc\n> which submodule it should purge? \"--purge=\"\n> maybe?\n\nThis might work, but at least the option would need to provide a\nhint to the user that it has something to do with submodules. So\nif the feature was implemented by `git gc` I'd rather name the\nparameter \"--purge-submodule=\" which in my\nopinion clearly states its intention, even though it is longer to\ntype. But with working bash-completion this should be non-issue,\nespecially as this command would not need to be run frequently.\n\nThat said, I think by now I agree with the common (?) opinion\nthat the command is best placed in `git submodule deinit --purge`\nand I will likely implement it there. Optionally I could\nimplement `git gc --purge-submodule=` as a second\nway to access the feature so that we have a way of purging them\nwithout using the submodules-interface. I doubt though that this\nwill provide much of a benefit as the user still has to be aware\nthat he is working with submodules as he has to provide the\n`--purge-submodule` option, so there is not much to be gained by\nthis.\n\nRegards\nPatrick\n"},{"id":"258516","messageId":"551310EF.8050700@web.de","threadId":"38822","inReplyTo":"20150325090631.GA370@pks-pc.localdomain","subject":"Re: [RFC] git submodule purge","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2015-03-25T19:47:59Z","receivedAt":"2015-03-25T19:47:59Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:\n> On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote:\n>> Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:\n>>> On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote:\n>>>> (+cc: Jens and Heiko, submodule experts)\n>>>> Hi,\n>>>>\n>>>> Patrick Steinhardt wrote:\n>>>>\n>>>>> This proposal is just for discussion. If there is any interest I\n>>>>> will implement the feature and send some patches.\n>>>>>\n>>>>> Currently it is hard to properly remove submodules. That is when\n>>>>> a submodule is deinitialized and removed from a repository the\n>>>>> directory '.git/modules/' will still be present and\n>>>>> there is no way to remove it despite manually calling `rm` on it.\n>>>>> I think there should be a command that is able to remove those\n>>>>> dangling repositories if the following conditions are met:\n>>>>>\n>>>>> - the submodule should not be initialized\n>>>>>\n>>>>> - the submodule should not have an entry in .gitmodules in the\n>>>>> currently checked out revision\n>>>>>\n>>>>> - the submodule should not contain any commits that are not\n>>>>> upstream\n>>>>>\n>>>>> - the submodule should not contain other submodules that do not\n>>>>> meet those conditions\n>>>>>\n>>>>> This would ensure that it is hard to loose any commits that may\n>>>>> be of interest. In the case that the user knows what he is doing\n>>>>> we may provide a '--force' switch to override those checks.\n>>>>\n>>>> Those conditions look simultaneously too strong and too weak. ;-)\n>>>>\n>>>> In principle, it should be safe to remove .git/modules/ as\n>>>> long as\n>>>>\n>>>> (1) it (and its submodules, sub-sub-modules, etc) doesn't have any\n>>>> un-pushed local commits.\n>>>>\n>>>> (2) it is not being referred to by a .git file in the work tree of\n>>>> the parent repository.\n>>>>\n>>>> Condition (1) can be relaxed if the user knows what they are losing\n>>>> and is okay with that. Condition (2) can be avoided by removing\n>>>> (de-initing) the copy of that submodule in the worktree at the same\n>>>> time.\n>>>>\n>>>> The functionality sounds like a useful thing to have, whether as an\n>>>> option to 'git submodule deinit' or as a new subcommand. In the long\n>>>> term I would like it to be possible to do everything 'git submodule'\n>>>> can do using normal git commands instead of that specialized\n>>>> interface. What command do you think this would eventually belong in?\n>>>> (An option to \"git gc\", maybe?)\n>>>>\n>>>> Thanks,\n>>>> Jonathan\n>>>\n>>> Thanks for your feedback.\n>>>\n>>> Considering that purging the submodule is tightly coupled with\n>>> de-initializing it, it might make sense to provide this\n>>> functionality as part of `git submodule deinit`. Maybe something\n>>> like `git submodule deinit --purge` would work for the user.\n>>> Problem is if the user first removes the submodule and does not\n>>> first deinitialize it he is not able to purge the repository\n>>> afterwards as deinit will complain about the submodule not being\n>>> matched anymore. We could just make `deinit --purge` work with\n>>> removed submodules, but that does not feel very natural to me.\n>>\n>> Hmm, cmd_deinit() seems to cope with submodules removed by the\n>> user just fine (as long as they are still present in the index).\n>> To me it feels natural to extend deinit to remove the repo from\n>> .git/modules too when --purge is given (as long as no unpushed\n>> commits are present or -f is given).\n>>\n>>> `git gc` feels saner in that regard, but I don't think it would\n>>> be easy to spot for users as this command is in general not used\n>>> very frequently by them. One could argue though that it does not\n>>> need to be discoverable.\n>>\n>> The error message of \"git submodule deinit --purge\" for a\n>> submodule that isn't recorded in the index anymore could point\n>> the user to the appropriate gc command. But how do we tell gc\n>> which submodule it should purge? \"--purge=\"\n>> maybe?\n>\n> This might work, but at least the option would need to provide a\n> hint to the user that it has something to do with submodules. So\n> if the feature was implemented by `git gc` I'd rather name the\n> parameter \"--purge-submodule=\" which in my\n> opinion clearly states its intention, even though it is longer to\n> type. But with working bash-completion this should be non-issue,\n> especially as this command would not need to be run frequently.\n\nAgreed.\n\n> That said, I think by now I agree with the common (?) opinion\n> that the command is best placed in `git submodule deinit --purge`\n> and I will likely implement it there.\n\nMe thinks that makes sense. But be aware that this will only work\nfor those submodules that are still present in the current index.\n\n> Optionally I could\n> implement `git gc --purge-submodule=` as a second\n> way to access the feature so that we have a way of purging them\n> without using the submodules-interface. I doubt though that this\n> will provide much of a benefit as the user still has to be aware\n> that he is working with submodules as he has to provide the\n> `--purge-submodule` option, so there is not much to be gained by\n> this.\n\nHmm, I still believe cleaning up a submodule repo which is already\ndeinited makes sense. Using 'rm -rf .git/modules/'\nwill work just fine, but is missing any safeguards. The deinit\ncommand takes submodule paths, not submodule names. So it looks\nto me like 'git gc --purge-submodule=' would make\nsense here (and this command should check that the submodule has\nalready been deinited and fail otherwise telling the user so).\n"},{"id":"258548","messageId":"20150326133052.GA382@pks-pc.localdomain","threadId":"38822","inReplyTo":"551310EF.8050700@web.de","subject":"Re: [RFC] git submodule purge","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-03-26T13:30:52Z","receivedAt":"2015-03-26T13:30:52Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:\n> Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:\n> > On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote:\n> >> Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:\n[snip]\n> >> Hmm, cmd_deinit() seems to cope with submodules removed by the\n> >> user just fine (as long as they are still present in the index).\n> >> To me it feels natural to extend deinit to remove the repo from\n> >> .git/modules too when --purge is given (as long as no unpushed\n> >> commits are present or -f is given).\n> >>\n> >>> `git gc` feels saner in that regard, but I don't think it would\n> >>> be easy to spot for users as this command is in general not used\n> >>> very frequently by them. One could argue though that it does not\n> >>> need to be discoverable.\n> >>\n> >> The error message of \"git submodule deinit --purge\" for a\n> >> submodule that isn't recorded in the index anymore could point\n> >> the user to the appropriate gc command. But how do we tell gc\n> >> which submodule it should purge? \"--purge=\"\n> >> maybe?\n> >\n> > This might work, but at least the option would need to provide a\n> > hint to the user that it has something to do with submodules. So\n> > if the feature was implemented by `git gc` I'd rather name the\n> > parameter \"--purge-submodule=\" which in my\n> > opinion clearly states its intention, even though it is longer to\n> > type. But with working bash-completion this should be non-issue,\n> > especially as this command would not need to be run frequently.\n> \n> Agreed.\n> \n> > That said, I think by now I agree with the common (?) opinion\n> > that the command is best placed in `git submodule deinit --purge`\n> > and I will likely implement it there.\n> \n> Me thinks that makes sense. But be aware that this will only work\n> for those submodules that are still present in the current index.\n> \n> > Optionally I could\n> > implement `git gc --purge-submodule=` as a second\n> > way to access the feature so that we have a way of purging them\n> > without using the submodules-interface. I doubt though that this\n> > will provide much of a benefit as the user still has to be aware\n> > that he is working with submodules as he has to provide the\n> > `--purge-submodule` option, so there is not much to be gained by\n> > this.\n> \n> Hmm, I still believe cleaning up a submodule repo which is already\n> deinited makes sense. Using 'rm -rf .git/modules/'\n> will work just fine, but is missing any safeguards. The deinit\n> command takes submodule paths, not submodule names. So it looks\n> to me like 'git gc --purge-submodule=' would make\n> sense here (and this command should check that the submodule has\n> already been deinited and fail otherwise telling the user so).\n\nAh, okay. I thought your intention was to provide `git gc\n--purge-sm` _instead_ of `git sm deinit --purge`. Guess it makes\nsense to have both available for the different use cases\n(explicitly removing a submodule vs removing unreferenced ones).\nI guess one could even provide another option\n`--purge-submodules` in addition to `--purge-sm=` that\nwill remove all deinitialized submodules without local commits.\nMaybe its desirable to have a `--dry-run` flag as well that would\nprint which repositories would be deleted by `--purge-sms`.\n\n\nPatrick\n"},{"id":"258573","messageId":"55147EA6.2000703@web.de","threadId":"38822","inReplyTo":"20150326133052.GA382@pks-pc.localdomain","subject":"Re: [RFC] git submodule purge","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2015-03-26T21:48:22Z","receivedAt":"2015-03-26T21:48:22Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.03.2015 um 14:30 schrieb Patrick Steinhardt:\n> On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:\n>> Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:\n>>> Optionally I could\n>>> implement `git gc --purge-submodule=` as a second\n>>> way to access the feature so that we have a way of purging them\n>>> without using the submodules-interface. I doubt though that this\n>>> will provide much of a benefit as the user still has to be aware\n>>> that he is working with submodules as he has to provide the\n>>> `--purge-submodule` option, so there is not much to be gained by\n>>> this.\n>>\n>> Hmm, I still believe cleaning up a submodule repo which is already\n>> deinited makes sense. Using 'rm -rf .git/modules/'\n>> will work just fine, but is missing any safeguards. The deinit\n>> command takes submodule paths, not submodule names. So it looks\n>> to me like 'git gc --purge-submodule=' would make\n>> sense here (and this command should check that the submodule has\n>> already been deinited and fail otherwise telling the user so).\n>\n> Ah, okay. I thought your intention was to provide `git gc\n> --purge-sm` _instead_ of `git sm deinit --purge`. Guess it makes\n> sense to have both available for the different use cases\n> (explicitly removing a submodule vs removing unreferenced ones).\n\nYup. And I wonder if `--purge` should be the default for deinit\nif no unpushed commits will be lost ... but let's hear what\nothers think about this one.\n\n> I guess one could even provide another option\n> `--purge-submodules` in addition to `--purge-sm=` that\n> will remove all deinitialized submodules without local commits.\n> Maybe its desirable to have a `--dry-run` flag as well that would\n> print which repositories would be deleted by `--purge-sms`.\n\nHmm, thinking about that some more maybe we might wanna simplify\nthis a bit. Adding a `--prune-submodules` option to gc which will\nremove all deinitialized submodules repos that don't have any\nunpushed commits should be sufficient to do the housekeeping. If\npeople demand to be able to prune specific submodules later we\ncould still add a `--prune-submodule=`, but I suspect we\nmight not need that.\n"}]}