From: Junio C Hamano Date: Thu, 16 Aug 2012 21:56:20 GMT Subject: Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules Message-ID: <7vmx1uzekb.fsf@alter.siamese.dyndns.org> In-Reply-To: <4FFB3DB9.6090808@web.de> 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.