On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 25.06.2012 12:57, schrieb Michał Górny: >> Add an 'rm' command to git-submodule which provides means to >> (semi-)easily remove git submodules. >> >> Signed-off-by: Michał Górny <mgorny@xxxxxxxxxx> >> --- >> Right now, it requires the submodule checkout to be removed manually >> first (so it does not remove unstaged commits), and just removes >> the index entry and module information from config. >> >> I based it on 'cmd_add' code trying to preserve the original coding >> standards. > > I really like the goal of this patch but would prefer that "git rm" > learns how to remove submodules instead of adding more code to the > git-submodule.sh script. I would like to see both supported, eventually. That is, git-rm and git-submodule-rm should both work. It would make sense to me when I am looking for the counterpart to 'git submodule add' to find it under 'git submodule rm', and also under 'git submodule --help'. > Also it shouldn't be necessary for the user to remove the directory > by hand before running "git rm". At least all files recorded in the > submodule can be removed (and if the submodule uses a gitfile that > can be removed too). Then all that is left are untracked files the > user has to decide what to do with (which might be removed too when > running "git rm --recurse-submodules=untracked"). That sounds like a nice next step. But I would expect that a 'git [submodule] rm foo' where foo has uncommitted changes to complain to me (and do nothing else) unless I used --force. This is similar to how git-rm already behaves, I think. And in the case of a dirty submodule it makes sense to treat the submodule files as an atomic unit. That is, if any of the submodule files are dirty and git-rm will "leave" them, then it should leave the whole submodule. It would be very inconvenient to have to restore files back into place at the correct commit just so I could examine them in context to determine what I should have done with them before I used git-rm. In the special case of a submodule which does not use a gitfile, I am not even sure if any of the submodule files should be removed. If they are, what state does that leave the submodule repository in? A checked-out workdir whose files are all removed? 'git-status' would be very noisy in this case. I'd rather expect this to behave the same as if I checked out a previous commit which did not have the submodule added yet. Today, this leaves the submodule in-place and it shows up as an untracked file. I don't know a better way to handle that, though I expect it would be ok remove all the files even in this case (if the workdir is not dirty and if the head commit is current in the superproject). But it seems extreme to do all of that and then leave the .git directory lying about in the former submodule directory. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html