Am 16.08.2012 23:56, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> Am 09.07.2012 21:38, schrieb Junio C Hamano: >>> Jens Lehmann <Jens.Lehmann@xxxxxx> 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. -- 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