From: Junio C Hamano Date: Mon, 09 Jul 2012 19:38:22 GMT Subject: Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules Message-ID: <7vpq84k9n5.fsf@alter.siamese.dyndns.org> In-Reply-To: <4FFB23EB.8060409@web.de> Jens Lehmann writes: > Cool, so let's drop this patch and I'll teach "rm" to handle > populated submodules according to what we do for regular files: > Make sure there are no modifications which could get lost (unless > "-f") and remove all tracked files and the gitfile from the work > tree (unless "--cached") before removing the submodule from the > index. If the submodule uses the old layout with the .git > directory instead of a gitfile we error out just like we do today. Alternatively we could "mv" .git directory out of the way and the next "git checkout" of a branch that still has the submodule can make a gitfile to point there, no? Or we can just error out and tell the user to do so herself. > And we didn't talk about untracked or ignored files which may live > inside the submodules work tree so far, but according to what a > "rm -r" does in the superproject they should still be around after > using "rm" on a populated submodule, right? Until we add the "precious" class, untracked and ignored files are expendable, so if a submodule working tree has no modification and only has leftover *.o files, they can be nuked as part of submodule removal, but if it has an untracked and unignored *.c file for example, the "rm" operation without "-f" should be stopped, no?