From: Jens Lehmann Date: Fri, 17 Aug 2012 16:44:40 GMT Subject: Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules Message-ID: <502E74F8.4070209@web.de> In-Reply-To: <7vmx1uzekb.fsf@alter.siamese.dyndns.org> Am 16.08.2012 23:56, schrieb Junio C Hamano: > Jens Lehmann writes: > >> Am 09.07.2012 21:38, schrieb Junio C Hamano: >>> 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? >> >> Yup. That would mean a smooth transition for legacy .git-dir >> submodules into the new gitfile world. >> >>>> 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? >> >> Ok, untracked files mark the submodule modified while ignored files >> which are not tracked won't. >> >> Thanks for this discussion, I'll start hacking on that. > > A mild ping on seemingly stalled topic. I'm almost there. The only thing left is to check if a nested submodule is using a git directory. In that case I expect "rm" to fail even when -f is used to protect the submodule's history. I still need to find a suitable command for recursing the submodules and doing that check.