Am 16.08.2012 23:56, schrieb Junio C Hamano:
> Jens Lehmann <jens.lehm...@web.de> writes:
>> 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.
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html