On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > 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. Maybe it would be better if 'git-rm' would use 'git submodule rm' under the covers. This would keep the .gitmodules (etc.) manipulations out of the hair of the git-rm machinery. Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule. >>> 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) So you did. What bothered me was the suggestion that you could partially remove a submodule's files. >> 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. I like this idea, but it seems a little presumptuous. The new behavior might cause a few panicked users to spend the day rebuilding their "lost" repository. Maybe we can make this an explicit action. "git submodule convert-to-gitfile" :-) 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