Am 09.07.2012 21:38, schrieb Junio C Hamano: > Jens Lehmann <jens.lehm...@web.de> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
