Am 25.06.2012 22:53, schrieb Phil Hord: > 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'. Hmm, as long as "git submodule rm" would just use "git rm" under the hood and not its own scripting that would be ok. >> 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. We absolutely agree here, this is pretty much what I wrote further down in my first response ;-) (except additionally I consider a submodule dirty if it's HEAD isn't on any branch to avoid loosing commits) > 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. Good point. Another option would be to move the git directory into .git/modules of the superproject before removing the files, then next time it's updated it'll use gitfile. But maybe that's a problem which will go away anyways as all submodules cloned with newer git use gitfiles anyway. -- 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