Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules

Jens Lehmann [off-list ref] 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?

Am 09.07.2012 21:38, schrieb Junio C Hamano:

Jens Lehmann [off-list ref] writes:

quoted

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.

quoted

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.