On Tue, Jun 26, 2012 at 3:59 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 26.06.2012 21:12, schrieb Phil Hord: >> 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. > > I disagree, me thinks submodules should become first class citizens. Sounds ok to me. But maybe keep it in a separate module just for manipulating submodules; you know, to reduce our spaghetti score. >> Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule. > > Yes, it should. But that'd be easy to test there. > >>>> 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. > > Me thinks we should teach "git rm" only to remove the submodule when > the --recurse-submodules option is used with it (which is what "git > submodule rm" would do). Then later the to be added "autoupdate" > submodule config setting (which I intend to use for automatic > submodule updates during checkout, merge, etc. too) could enable this. > No surprises for users who didn't ask for it. I like that, though I despise the --recurse-submodules option because A) it is too long, and B) it is sometimes spelled "--recurse" (for good reasons, I'm sure, but it's irritating nonetheless). >> Maybe we can make this an explicit action. >> "git submodule convert-to-gitfile" :-) > > I like it! -- 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