{"thread":{"id":"30892","subject":"[PATCH 1/2] git-submodule.sh: fix filename in comment.","startedAt":"2012-06-25T10:56:59Z","lastAt":"2012-06-28T20:31:06Z","messageCount":9,"participants":["Michał Górny","Jens Lehmann","Phil Hord"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"194195","messageId":"1340621820-19448-1-git-send-email-mgorny@gentoo.org","threadId":"30892","inReplyTo":null,"subject":"[PATCH 1/2] git-submodule.sh: fix filename in comment.","fromName":"Michał Górny","fromEmail":"mgorny@gentoo.org","sentAt":"2012-06-25T10:56:59Z","receivedAt":"2012-06-25T10:56:59Z","isPatch":true,"sender":{"key":"mgorny@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/110765?v=4"},"body":"Signed-off-by: Michał Górny <mgorny@gentoo.org>\n---\n git-submodule.sh |    2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 5c61ae2..fbf2faf 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -1,6 +1,6 @@\n #!/bin/sh\n #\n-# git-submodules.sh: add, init, update or list git submodules\n+# git-submodule.sh: add, init, update or list git submodules\n #\n # Copyright (c) 2007 Lars Hjemli\n \n-- \n1.7.10.2\n"},{"id":"194196","messageId":"1340621820-19448-2-git-send-email-mgorny@gentoo.org","threadId":"30892","inReplyTo":"1340621820-19448-1-git-send-email-mgorny@gentoo.org","subject":"[PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Michał Górny","fromEmail":"mgorny@gentoo.org","sentAt":"2012-06-25T10:57:00Z","receivedAt":"2012-06-25T10:57:00Z","isPatch":true,"sender":{"key":"mgorny@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/110765?v=4"},"body":"Add an 'rm' command to git-submodule which provides means to\n(semi-)easily remove git submodules.\n\nSigned-off-by: Michał Górny <mgorny@gentoo.org>\n---\nRight now, it requires the submodule checkout to be removed manually\nfirst (so it does not remove unstaged commits), and just removes\nthe index entry and module information from config.\n\nI based it on 'cmd_add' code trying to preserve the original coding\nstandards.\n\n Documentation/git-submodule.txt |   12 +++++++\n git-submodule.sh                |   68 ++++++++++++++++++++++++++++++++++++++-\n 2 files changed, 79 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex fbbbcb2..293c1bf 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -11,6 +11,7 @@ SYNOPSIS\n [verse]\n 'git submodule' [--quiet] add [-b branch] [-f|--force]\n \t      [--reference <repository>] [--] <repository> [<path>]\n+'git submodule' [--quiet] rm <path>...\n 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]\n 'git submodule' [--quiet] init [--] [<path>...]\n 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n@@ -104,6 +105,17 @@ together in the same relative location, and only the\n superproject's URL needs to be provided: git-submodule will correctly\n locate the submodule using the relative URL in .gitmodules.\n \n+rm::\n+\tRemove and unregister the submodules at given paths.\n++\n+This requires at least one <path> argument. The repository checkout\n+existing at that directory needs to be removed manually from\n+the filesystem prior to calling this command. Note that all local\n+changes will be lost.\n++\n+This command removes the submodule from the current git index,\n+the .gitmodules file and the local repository config.\n+\n status::\n \tShow the status of the submodules. This will print the SHA-1 of the\n \tcurrently checked out commit for each submodule, along with the\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex fbf2faf..88fd414 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -6,6 +6,7 @@\n \n dashless=$(basename \"$0\" | sed -e 's/-/ /')\n USAGE=\"[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]\n+   or: $dashless [--quiet] rm [--] <path>...\n    or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]\n    or: $dashless [--quiet] init [--] [<path>...]\n    or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]\n@@ -308,6 +309,71 @@ Use -f if you really want to add it.\" >&2\n }\n \n #\n+# Remove submodules from the working tree, .gitmodules and the index\n+#\n+# $@ = submodule paths\n+#\n+cmd_rm()\n+{\n+\t# parse $args after \"submodule ... rm\".\n+\twhile test $# -ne 0\n+\tdo\n+\t\tcase \"$1\" in\n+\t\t--)\n+\t\t\tshift\n+\t\t\tbreak\n+\t\t\t;;\n+\t\t-*)\n+\t\t\tusage\n+\t\t\t;;\n+\t\t*)\n+\t\t\tbreak\n+\t\t\t;;\n+\t\tesac\n+\t\tshift\n+\tdone\n+\n+\tif test -z \"$1\"; then\n+\t\tusage\n+\tfi\n+\n+\twhile test $# -ne 0\n+\tdo\n+\t\tsm_path=$1\n+\t\tshift\n+\n+\t\t# normalize path:\n+\t\t# multiple //; leading ./; /./; /../; trailing /\n+\t\tsm_path=$(printf '%s/\\n' \"$sm_path\" |\n+\t\t\tsed -e '\n+\t\t\t\ts|//*|/|g\n+\t\t\t\ts|^\\(\\./\\)*||\n+\t\t\t\ts|/\\./|/|g\n+\t\t\t\t:start\n+\t\t\t\ts|\\([^/]*\\)/\\.\\./||\n+\t\t\t\ttstart\n+\t\t\t\ts|/*$||\n+\t\t\t')\n+\t\tgit ls-files --error-unmatch \"$sm_path\" > /dev/null 2>&1 ||\n+\t\tdie \"$(eval_gettext \"'\\$sm_path' does not exist in the index\")\"\n+\n+\t\tif test -e \"$sm_path\"\n+\t\tthen\n+\t\t\tdie \"$(eval_gettext \"'\\$sm_path' needs to be removed manually first\")\"\n+\t\tfi\n+\n+\t\tgit rm --cached \"$sm_path\" ||\n+\t\tdie \"$(eval_gettext \"Failed to remove submodule '\\$sm_path'\")\"\n+\n+\t\tgit config -f .gitmodules --remove-section submodule.\"$sm_path\" &&\n+\t\tgit add --force .gitmodules ||\n+\t\tdie \"$(eval_gettext \"Failed to unregister submodule '\\$sm_path'\")\"\n+\n+\t\tgit config --remove-section submodule.\"$sm_path\"\n+\tdone\n+}\n+\n+#\n # Execute an arbitrary command sequence in each checked out\n # submodule\n #\n@@ -996,7 +1062,7 @@ cmd_sync()\n while test $# != 0 && test -z \"$command\"\n do\n \tcase \"$1\" in\n-\tadd | foreach | init | update | status | summary | sync)\n+\tadd | rm | foreach | init | update | status | summary | sync)\n \t\tcommand=$1\n \t\t;;\n \t-q|--quiet)\n-- \n1.7.10.2\n"},{"id":"194215","messageId":"4FE898BC.2020307@web.de","threadId":"30892","inReplyTo":"1340621820-19448-2-git-send-email-mgorny@gentoo.org","subject":"Re: [PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-06-25T16:58:36Z","receivedAt":"2012-06-25T16:58:36Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 25.06.2012 12:57, schrieb Michał Górny:\n> Add an 'rm' command to git-submodule which provides means to\n> (semi-)easily remove git submodules.\n> \n> Signed-off-by: Michał Górny <mgorny@gentoo.org>\n> ---\n> Right now, it requires the submodule checkout to be removed manually\n> first (so it does not remove unstaged commits), and just removes\n> the index entry and module information from config.\n> \n> I based it on 'cmd_add' code trying to preserve the original coding\n> standards.\n\nI really like the goal of this patch but would prefer that \"git rm\"\nlearns how to remove submodules instead of adding more code to the\ngit-submodule.sh script.\n\nAlso it shouldn't be necessary for the user to remove the directory\nby hand before running \"git rm\". At least all files recorded in the\nsubmodule can be removed (and if the submodule uses a gitfile that\ncan be removed too). Then all that is left are untracked files the\nuser has to decide what to do with (which might be removed too when\nrunning \"git rm --recurse-submodules=untracked\").\n\n>  Documentation/git-submodule.txt |   12 +++++++\n>  git-submodule.sh                |   68 ++++++++++++++++++++++++++++++++++++++-\n>  2 files changed, 79 insertions(+), 1 deletion(-)\n> \n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index fbbbcb2..293c1bf 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -11,6 +11,7 @@ SYNOPSIS\n>  [verse]\n>  'git submodule' [--quiet] add [-b branch] [-f|--force]\n>  \t      [--reference <repository>] [--] <repository> [<path>]\n> +'git submodule' [--quiet] rm <path>...\n>  'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]\n>  'git submodule' [--quiet] init [--] [<path>...]\n>  'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n> @@ -104,6 +105,17 @@ together in the same relative location, and only the\n>  superproject's URL needs to be provided: git-submodule will correctly\n>  locate the submodule using the relative URL in .gitmodules.\n>  \n> +rm::\n> +\tRemove and unregister the submodules at given paths.\n> ++\n> +This requires at least one <path> argument. The repository checkout\n> +existing at that directory needs to be removed manually from\n> +the filesystem prior to calling this command. Note that all local\n> +changes will be lost.\n\nMe thinks without -f a \"git rm\" should only then remove a submodule\nif no local modifications exist and current HEAD is part of a remote\nbranch (so you can't loose unpushed commits by accident). If the\nsubmodule uses a gitfile a local branch might be sufficient for that,\nas the git directory lives on.\n\n> ++\n> +This command removes the submodule from the current git index,\n> +the .gitmodules file and the local repository config.\n\nIt should not be removed from .git/config by default. The user may\nhave special settings there and the presence in .git/config shows\nhe cared about having the submodule checked out, which should not\nbe revoked by just removing the submodule from the work tree.\nUnless he removes the config from there himself he should get back\na populated submodule when he checks out an earlier commit and says\n\"git submodule update\".\n\n>  status::\n>  \tShow the status of the submodules. This will print the SHA-1 of the\n>  \tcurrently checked out commit for each submodule, along with the\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index fbf2faf..88fd414 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -6,6 +6,7 @@\n>  \n>  dashless=$(basename \"$0\" | sed -e 's/-/ /')\n>  USAGE=\"[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]\n> +   or: $dashless [--quiet] rm [--] <path>...\n>     or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]\n>     or: $dashless [--quiet] init [--] [<path>...]\n>     or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]\n> @@ -308,6 +309,71 @@ Use -f if you really want to add it.\" >&2\n>  }\n>  \n>  #\n> +# Remove submodules from the working tree, .gitmodules and the index\n> +#\n> +# $@ = submodule paths\n> +#\n> +cmd_rm()\n> +{\n> +\t# parse $args after \"submodule ... rm\".\n> +\twhile test $# -ne 0\n> +\tdo\n> +\t\tcase \"$1\" in\n> +\t\t--)\n> +\t\t\tshift\n> +\t\t\tbreak\n> +\t\t\t;;\n> +\t\t-*)\n> +\t\t\tusage\n> +\t\t\t;;\n> +\t\t*)\n> +\t\t\tbreak\n> +\t\t\t;;\n> +\t\tesac\n> +\t\tshift\n> +\tdone\n> +\n> +\tif test -z \"$1\"; then\n> +\t\tusage\n> +\tfi\n> +\n> +\twhile test $# -ne 0\n> +\tdo\n> +\t\tsm_path=$1\n> +\t\tshift\n> +\n> +\t\t# normalize path:\n> +\t\t# multiple //; leading ./; /./; /../; trailing /\n> +\t\tsm_path=$(printf '%s/\\n' \"$sm_path\" |\n> +\t\t\tsed -e '\n> +\t\t\t\ts|//*|/|g\n> +\t\t\t\ts|^\\(\\./\\)*||\n> +\t\t\t\ts|/\\./|/|g\n> +\t\t\t\t:start\n> +\t\t\t\ts|\\([^/]*\\)/\\.\\./||\n> +\t\t\t\ttstart\n> +\t\t\t\ts|/*$||\n> +\t\t\t')\n> +\t\tgit ls-files --error-unmatch \"$sm_path\" > /dev/null 2>&1 ||\n> +\t\tdie \"$(eval_gettext \"'\\$sm_path' does not exist in the index\")\"\n> +\n> +\t\tif test -e \"$sm_path\"\n> +\t\tthen\n> +\t\t\tdie \"$(eval_gettext \"'\\$sm_path' needs to be removed manually first\")\"\n> +\t\tfi\n> +\n> +\t\tgit rm --cached \"$sm_path\" ||\n> +\t\tdie \"$(eval_gettext \"Failed to remove submodule '\\$sm_path'\")\"\n> +\n> +\t\tgit config -f .gitmodules --remove-section submodule.\"$sm_path\" &&\n> +\t\tgit add --force .gitmodules ||\n> +\t\tdie \"$(eval_gettext \"Failed to unregister submodule '\\$sm_path'\")\"\n> +\n> +\t\tgit config --remove-section submodule.\"$sm_path\"\n> +\tdone\n> +}\n> +\n> +#\n>  # Execute an arbitrary command sequence in each checked out\n>  # submodule\n>  #\n> @@ -996,7 +1062,7 @@ cmd_sync()\n>  while test $# != 0 && test -z \"$command\"\n>  do\n>  \tcase \"$1\" in\n> -\tadd | foreach | init | update | status | summary | sync)\n> +\tadd | rm | foreach | init | update | status | summary | sync)\n>  \t\tcommand=$1\n>  \t\t;;\n>  \t-q|--quiet)\n> \n"},{"id":"194229","messageId":"CABURp0od-nNFVhLQU9BsiJ=wXkdneJfhxun_PHOfV=sgzOFShg@mail.gmail.com","threadId":"30892","inReplyTo":"4FE898BC.2020307@web.de","subject":"Re: [PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-06-25T20:53:54Z","receivedAt":"2012-06-25T20:53:54Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> Am 25.06.2012 12:57, schrieb Michał Górny:\n>> Add an 'rm' command to git-submodule which provides means to\n>> (semi-)easily remove git submodules.\n>>\n>> Signed-off-by: Michał Górny <mgorny@gentoo.org>\n>> ---\n>> Right now, it requires the submodule checkout to be removed manually\n>> first (so it does not remove unstaged commits), and just removes\n>> the index entry and module information from config.\n>>\n>> I based it on 'cmd_add' code trying to preserve the original coding\n>> standards.\n>\n> I really like the goal of this patch but would prefer that \"git rm\"\n> learns how to remove submodules instead of adding more code to the\n> git-submodule.sh script.\n\nI would like to see both supported, eventually. That is, git-rm and\ngit-submodule-rm should both work.  It would make sense to me when I\nam looking for the counterpart to 'git submodule add' to find it under\n'git submodule rm', and also under 'git submodule --help'.\n\n\n> Also it shouldn't be necessary for the user to remove the directory\n> by hand before running \"git rm\". At least all files recorded in the\n> submodule can be removed (and if the submodule uses a gitfile that\n> can be removed too). Then all that is left are untracked files the\n> user has to decide what to do with (which might be removed too when\n> running \"git rm --recurse-submodules=untracked\").\n\nThat sounds like a nice next step.  But I would expect that a 'git\n[submodule] rm foo' where foo has uncommitted changes to complain to\nme (and do nothing else) unless I used --force.  This is similar to\nhow git-rm already behaves, I think.  And in the case of a dirty\nsubmodule it makes sense to treat the submodule files as an atomic\nunit.  That is, if any of the submodule files are dirty and git-rm\nwill \"leave\" them, then it should leave the whole submodule.  It would\nbe very inconvenient to have to restore files back into place at the\ncorrect commit just so I could examine them in context to determine\nwhat I should have done with them before I used git-rm.\n\nIn the special case of a submodule which does not use a gitfile, I am\nnot even sure if any of the submodule files should be removed. If they\nare, what state does that leave the submodule repository in?  A\nchecked-out workdir whose files are all removed?  'git-status' would\nbe very noisy in this case.  I'd rather expect this to behave the same\nas if I checked out a previous commit which did not have the submodule\nadded yet.  Today, this leaves the submodule in-place and it shows up\nas an untracked file.  I don't know a better way to handle that,\nthough I expect it would be ok remove all the files even in this case\n(if the workdir is not dirty and if the head commit is current in the\nsuperproject).  But it seems extreme to do all of that and then leave\nthe .git directory lying about in the former submodule directory.\n\nPhil\n"},{"id":"194230","messageId":"4FE8D380.20803@web.de","threadId":"30892","inReplyTo":"CABURp0od-nNFVhLQU9BsiJ=wXkdneJfhxun_PHOfV=sgzOFShg@mail.gmail.com","subject":"Re: [PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-06-25T21:09:20Z","receivedAt":"2012-06-25T21:09:20Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 25.06.2012 22:53, schrieb Phil Hord:\n> On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>> Am 25.06.2012 12:57, schrieb Michał Górny:\n>>> Add an 'rm' command to git-submodule which provides means to\n>>> (semi-)easily remove git submodules.\n>>>\n>>> Signed-off-by: Michał Górny <mgorny@gentoo.org>\n>>> ---\n>>> Right now, it requires the submodule checkout to be removed manually\n>>> first (so it does not remove unstaged commits), and just removes\n>>> the index entry and module information from config.\n>>>\n>>> I based it on 'cmd_add' code trying to preserve the original coding\n>>> standards.\n>>\n>> I really like the goal of this patch but would prefer that \"git rm\"\n>> learns how to remove submodules instead of adding more code to the\n>> git-submodule.sh script.\n> \n> I would like to see both supported, eventually. That is, git-rm and\n> git-submodule-rm should both work.  It would make sense to me when I\n> am looking for the counterpart to 'git submodule add' to find it under\n> 'git submodule rm', and also under 'git submodule --help'.\n\nHmm, as long as \"git submodule rm\" would just use \"git rm\" under the\nhood and not its own scripting that would be ok.\n\n>> Also it shouldn't be necessary for the user to remove the directory\n>> by hand before running \"git rm\". At least all files recorded in the\n>> submodule can be removed (and if the submodule uses a gitfile that\n>> can be removed too). Then all that is left are untracked files the\n>> user has to decide what to do with (which might be removed too when\n>> running \"git rm --recurse-submodules=untracked\").\n> \n> That sounds like a nice next step.  But I would expect that a 'git\n> [submodule] rm foo' where foo has uncommitted changes to complain to\n> me (and do nothing else) unless I used --force.  This is similar to\n> how git-rm already behaves, I think.  And in the case of a dirty\n> submodule it makes sense to treat the submodule files as an atomic\n> unit.  That is, if any of the submodule files are dirty and git-rm\n> will \"leave\" them, then it should leave the whole submodule.  It would\n> be very inconvenient to have to restore files back into place at the\n> correct commit just so I could examine them in context to determine\n> what I should have done with them before I used git-rm.\n\nWe absolutely agree here, this is pretty much what I wrote further\ndown in my first response ;-)\n(except additionally I consider a submodule dirty if it's HEAD isn't\non any branch to avoid loosing commits)\n\n> In the special case of a submodule which does not use a gitfile, I am\n> not even sure if any of the submodule files should be removed. If they\n> are, what state does that leave the submodule repository in?  A\n> checked-out workdir whose files are all removed?  'git-status' would\n> be very noisy in this case.  I'd rather expect this to behave the same\n> as if I checked out a previous commit which did not have the submodule\n> added yet.  Today, this leaves the submodule in-place and it shows up\n> as an untracked file.  I don't know a better way to handle that,\n> though I expect it would be ok remove all the files even in this case\n> (if the workdir is not dirty and if the head commit is current in the\n> superproject).  But it seems extreme to do all of that and then leave\n> the .git directory lying about in the former submodule directory.\n\nGood point. Another option would be to move the git directory into\n.git/modules of the superproject before removing the files, then next\ntime it's updated it'll use gitfile. But maybe that's a problem which\nwill go away anyways as all submodules cloned with newer git use\ngitfiles anyway.\n"},{"id":"194303","messageId":"CABURp0qFXGs6wqFbz28OKywVsFu23JKfhS8uLsen-nqhBvDAiw@mail.gmail.com","threadId":"30892","inReplyTo":"4FE8D380.20803@web.de","subject":"Re: [PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-06-26T19:12:33Z","receivedAt":"2012-06-26T19:12:33Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> Am 25.06.2012 22:53, schrieb Phil Hord:\n>> On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>>> Am 25.06.2012 12:57, schrieb Michał Górny:\n>>>> Add an 'rm' command to git-submodule which provides means to\n>>>> (semi-)easily remove git submodules.\n>>>>\n>>>> Signed-off-by: Michał Górny <mgorny@gentoo.org>\n>>>> ---\n>>>> Right now, it requires the submodule checkout to be removed manually\n>>>> first (so it does not remove unstaged commits), and just removes\n>>>> the index entry and module information from config.\n>>>>\n>>>> I based it on 'cmd_add' code trying to preserve the original coding\n>>>> standards.\n>>>\n>>> I really like the goal of this patch but would prefer that \"git rm\"\n>>> learns how to remove submodules instead of adding more code to the\n>>> git-submodule.sh script.\n>>\n>> I would like to see both supported, eventually. That is, git-rm and\n>> git-submodule-rm should both work.  It would make sense to me when I\n>> am looking for the counterpart to 'git submodule add' to find it under\n>> 'git submodule rm', and also under 'git submodule --help'.\n>\n> Hmm, as long as \"git submodule rm\" would just use \"git rm\" under the\n> hood and not its own scripting that would be ok.\n\nMaybe it would be better if 'git-rm' would use 'git submodule rm'\nunder the covers.  This would keep the .gitmodules (etc.)\nmanipulations out of the hair of the git-rm machinery.\n\nAlso, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule.\n\n>>> Also it shouldn't be necessary for the user to remove the directory\n>>> by hand before running \"git rm\". At least all files recorded in the\n>>> submodule can be removed (and if the submodule uses a gitfile that\n>>> can be removed too). Then all that is left are untracked files the\n>>> user has to decide what to do with (which might be removed too when\n>>> running \"git rm --recurse-submodules=untracked\").\n>>\n>> That sounds like a nice next step.  But I would expect that a 'git\n>> [submodule] rm foo' where foo has uncommitted changes to complain to\n>> me (and do nothing else) unless I used --force.  This is similar to\n>> how git-rm already behaves, I think.  And in the case of a dirty\n>> submodule it makes sense to treat the submodule files as an atomic\n>> unit.  That is, if any of the submodule files are dirty and git-rm\n>> will \"leave\" them, then it should leave the whole submodule.  It would\n>> be very inconvenient to have to restore files back into place at the\n>> correct commit just so I could examine them in context to determine\n>> what I should have done with them before I used git-rm.\n>\n> We absolutely agree here, this is pretty much what I wrote further\n> down in my first response ;-)\n> (except additionally I consider a submodule dirty if it's HEAD isn't\n> on any branch to avoid loosing commits)\n\nSo you did.  What bothered me was the suggestion that you could\npartially remove a submodule's files.\n\n>> In the special case of a submodule which does not use a gitfile, I am\n>> not even sure if any of the submodule files should be removed. If they\n>> are, what state does that leave the submodule repository in?  A\n>> checked-out workdir whose files are all removed?  'git-status' would\n>> be very noisy in this case.  I'd rather expect this to behave the same\n>> as if I checked out a previous commit which did not have the submodule\n>> added yet.  Today, this leaves the submodule in-place and it shows up\n>> as an untracked file.  I don't know a better way to handle that,\n>> though I expect it would be ok remove all the files even in this case\n>> (if the workdir is not dirty and if the head commit is current in the\n>> superproject).  But it seems extreme to do all of that and then leave\n>> the .git directory lying about in the former submodule directory.\n>\n> Good point. Another option would be to move the git directory into\n> .git/modules of the superproject before removing the files, then next\n> time it's updated it'll use gitfile. But maybe that's a problem which\n> will go away anyways as all submodules cloned with newer git use\n> gitfiles anyway.\n\nI like this idea, but it seems a little presumptuous.  The new\nbehavior might cause a few panicked users to spend the day rebuilding\ntheir \"lost\" repository.  Maybe we can make this an explicit action.\n\"git submodule convert-to-gitfile\"  :-)\n\nPhil\n"},{"id":"194309","messageId":"4FEA1494.404@web.de","threadId":"30892","inReplyTo":"CABURp0qFXGs6wqFbz28OKywVsFu23JKfhS8uLsen-nqhBvDAiw@mail.gmail.com","subject":"Re: [PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-06-26T19:59:16Z","receivedAt":"2012-06-26T19:59:16Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.06.2012 21:12, schrieb Phil Hord:\n> On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>> Am 25.06.2012 22:53, schrieb Phil Hord:\n>>> On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>>>> Am 25.06.2012 12:57, schrieb Michał Górny:\n>>>>> Add an 'rm' command to git-submodule which provides means to\n>>>>> (semi-)easily remove git submodules.\n>>>>>\n>>>>> Signed-off-by: Michał Górny <mgorny@gentoo.org>\n>>>>> ---\n>>>>> Right now, it requires the submodule checkout to be removed manually\n>>>>> first (so it does not remove unstaged commits), and just removes\n>>>>> the index entry and module information from config.\n>>>>>\n>>>>> I based it on 'cmd_add' code trying to preserve the original coding\n>>>>> standards.\n>>>>\n>>>> I really like the goal of this patch but would prefer that \"git rm\"\n>>>> learns how to remove submodules instead of adding more code to the\n>>>> git-submodule.sh script.\n>>>\n>>> I would like to see both supported, eventually. That is, git-rm and\n>>> git-submodule-rm should both work.  It would make sense to me when I\n>>> am looking for the counterpart to 'git submodule add' to find it under\n>>> 'git submodule rm', and also under 'git submodule --help'.\n>>\n>> Hmm, as long as \"git submodule rm\" would just use \"git rm\" under the\n>> hood and not its own scripting that would be ok.\n> \n> Maybe it would be better if 'git-rm' would use 'git submodule rm'\n> under the covers.  This would keep the .gitmodules (etc.)\n> manipulations out of the hair of the git-rm machinery.\n\nI disagree, me thinks submodules should become first class citizens.\n\n> Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule.\n\nYes, it should. But that'd be easy to test there.\n\n>>> In the special case of a submodule which does not use a gitfile, I am\n>>> not even sure if any of the submodule files should be removed. If they\n>>> are, what state does that leave the submodule repository in?  A\n>>> checked-out workdir whose files are all removed?  'git-status' would\n>>> be very noisy in this case.  I'd rather expect this to behave the same\n>>> as if I checked out a previous commit which did not have the submodule\n>>> added yet.  Today, this leaves the submodule in-place and it shows up\n>>> as an untracked file.  I don't know a better way to handle that,\n>>> though I expect it would be ok remove all the files even in this case\n>>> (if the workdir is not dirty and if the head commit is current in the\n>>> superproject).  But it seems extreme to do all of that and then leave\n>>> the .git directory lying about in the former submodule directory.\n>>\n>> Good point. Another option would be to move the git directory into\n>> .git/modules of the superproject before removing the files, then next\n>> time it's updated it'll use gitfile. But maybe that's a problem which\n>> will go away anyways as all submodules cloned with newer git use\n>> gitfiles anyway.\n> \n> I like this idea, but it seems a little presumptuous.  The new\n> behavior might cause a few panicked users to spend the day rebuilding\n> their \"lost\" repository.\n\nMe thinks we should teach \"git rm\" only to remove the submodule when\nthe --recurse-submodules option is used with it (which is what \"git\nsubmodule rm\" would do). Then later the to be added \"autoupdate\"\nsubmodule config  setting (which I intend to use for automatic\nsubmodule updates during checkout, merge, etc. too) could enable this.\nNo surprises for users who didn't ask for it.\n\n>  Maybe we can make this an explicit action.\n> \"git submodule convert-to-gitfile\"  :-)\n\nI like it!\n"},{"id":"194364","messageId":"CABURp0p-PL3E2wfPptL7KcwQaiK+p3oAa_aQ7R=Jge6oVvJ8iA@mail.gmail.com","threadId":"30892","inReplyTo":"4FEA1494.404@web.de","subject":"Re: [PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-06-27T18:48:49Z","receivedAt":"2012-06-27T18:48:49Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Jun 26, 2012 at 3:59 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> Am 26.06.2012 21:12, schrieb Phil Hord:\n>> On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>>> Am 25.06.2012 22:53, schrieb Phil Hord:\n>>>> On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n>>>>> Am 25.06.2012 12:57, schrieb Michał Górny:\n>>>>>> Add an 'rm' command to git-submodule which provides means to\n>>>>>> (semi-)easily remove git submodules.\n>>>>>>\n>>>>>> Signed-off-by: Michał Górny <mgorny@gentoo.org>\n>>>>>> ---\n>>>>>> Right now, it requires the submodule checkout to be removed manually\n>>>>>> first (so it does not remove unstaged commits), and just removes\n>>>>>> the index entry and module information from config.\n>>>>>>\n>>>>>> I based it on 'cmd_add' code trying to preserve the original coding\n>>>>>> standards.\n>>>>>\n>>>>> I really like the goal of this patch but would prefer that \"git rm\"\n>>>>> learns how to remove submodules instead of adding more code to the\n>>>>> git-submodule.sh script.\n>>>>\n>>>> I would like to see both supported, eventually. That is, git-rm and\n>>>> git-submodule-rm should both work.  It would make sense to me when I\n>>>> am looking for the counterpart to 'git submodule add' to find it under\n>>>> 'git submodule rm', and also under 'git submodule --help'.\n>>>\n>>> Hmm, as long as \"git submodule rm\" would just use \"git rm\" under the\n>>> hood and not its own scripting that would be ok.\n>>\n>> Maybe it would be better if 'git-rm' would use 'git submodule rm'\n>> under the covers.  This would keep the .gitmodules (etc.)\n>> manipulations out of the hair of the git-rm machinery.\n>\n> I disagree, me thinks submodules should become first class citizens.\n\nSounds ok to me.  But maybe keep it in a separate module just for\nmanipulating submodules; you know, to reduce our spaghetti score.\n\n>> Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule.\n>\n> Yes, it should. But that'd be easy to test there.\n>\n>>>> In the special case of a submodule which does not use a gitfile, I am\n>>>> not even sure if any of the submodule files should be removed. If they\n>>>> are, what state does that leave the submodule repository in?  A\n>>>> checked-out workdir whose files are all removed?  'git-status' would\n>>>> be very noisy in this case.  I'd rather expect this to behave the same\n>>>> as if I checked out a previous commit which did not have the submodule\n>>>> added yet.  Today, this leaves the submodule in-place and it shows up\n>>>> as an untracked file.  I don't know a better way to handle that,\n>>>> though I expect it would be ok remove all the files even in this case\n>>>> (if the workdir is not dirty and if the head commit is current in the\n>>>> superproject).  But it seems extreme to do all of that and then leave\n>>>> the .git directory lying about in the former submodule directory.\n>>>\n>>> Good point. Another option would be to move the git directory into\n>>> .git/modules of the superproject before removing the files, then next\n>>> time it's updated it'll use gitfile. But maybe that's a problem which\n>>> will go away anyways as all submodules cloned with newer git use\n>>> gitfiles anyway.\n>>\n>> I like this idea, but it seems a little presumptuous.  The new\n>> behavior might cause a few panicked users to spend the day rebuilding\n>> their \"lost\" repository.\n>\n> Me thinks we should teach \"git rm\" only to remove the submodule when\n> the --recurse-submodules option is used with it (which is what \"git\n> submodule rm\" would do). Then later the to be added \"autoupdate\"\n> submodule config  setting (which I intend to use for automatic\n> submodule updates during checkout, merge, etc. too) could enable this.\n> No surprises for users who didn't ask for it.\n\nI like that, though I despise the --recurse-submodules option because\nA) it is too long, and B) it is sometimes spelled \"--recurse\" (for\ngood reasons, I'm sure, but it's irritating nonetheless).\n\n>>  Maybe we can make this an explicit action.\n>> \"git submodule convert-to-gitfile\"  :-)\n>\n> I like it!\n"},{"id":"194416","messageId":"20120628223106.5bc9735e@pomiocik.lan","threadId":"30892","inReplyTo":"4FE898BC.2020307@web.de","subject":"Re: [PATCH 2/2] git-submodule: support 'rm' command.","fromName":"Michał Górny","fromEmail":"mgorny@gentoo.org","sentAt":"2012-06-28T20:31:06Z","receivedAt":"2012-06-28T20:31:06Z","isPatch":true,"sender":{"key":"mgorny@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/110765?v=4"},"body":"On Mon, 25 Jun 2012 18:58:36 +0200\nJens Lehmann <Jens.Lehmann@web.de> wrote:\n\n> Am 25.06.2012 12:57, schrieb Michał Górny:\n> > Add an 'rm' command to git-submodule which provides means to\n> > (semi-)easily remove git submodules.\n> > \n> > Signed-off-by: Michał Górny <mgorny@gentoo.org>\n> > ---\n> > Right now, it requires the submodule checkout to be removed manually\n> > first (so it does not remove unstaged commits), and just removes\n> > the index entry and module information from config.\n> > \n> > I based it on 'cmd_add' code trying to preserve the original coding\n> > standards.\n> \n> I really like the goal of this patch but would prefer that \"git rm\"\n> learns how to remove submodules instead of adding more code to the\n> git-submodule.sh script.\n\nMy main intent was, like Phil already pointed out, to provide\na counterpart to 'git submodule add'. I don't mind 'git rm' supporting\nremoving submodules but that's not exactly what I would consider...\nfriendly?\n\nWhat I'm trying to express is that if I added a submodule using 'git\nsubmodule add', I would expect to have 'git submodule rm'. Honestly, I\ndidn't even think about trying using 'git rm' on a submodule.\nThe correct results of such a call are hard to predict to me.\n\n> Also it shouldn't be necessary for the user to remove the directory\n> by hand before running \"git rm\". At least all files recorded in the\n> submodule can be removed (and if the submodule uses a gitfile that\n> can be removed too). Then all that is left are untracked files the\n> user has to decide what to do with (which might be removed too when\n> running \"git rm --recurse-submodules=untracked\").\n\nExcept for the untracked files there may also be commits which were not\npushed anywhere. Honestly, I didn't want to get into that risky area in\nthe first patch.\n\nAs the next step, I'd see adding a '--force' option to actually enforce\nremoving the directory. But I'd like the basics to start working first,\nthen consider harder things.\n\n> > ++\n> > +This command removes the submodule from the current git index,\n> > +the .gitmodules file and the local repository config.\n> \n> It should not be removed from .git/config by default. The user may\n> have special settings there and the presence in .git/config shows\n> he cared about having the submodule checked out, which should not\n> be revoked by just removing the submodule from the work tree.\n> Unless he removes the config from there himself he should get back\n> a populated submodule when he checks out an earlier commit and says\n> \"git submodule update\".\n\nOk, I will change that.\n\n-- \nBest regards,\nMichał Górny\n"}]}