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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 8, 2012, 07:32 UTC
Message-ID: <7vsjd2n1wt.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4FF830D6.7080708@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 23 quoted lines

>> One possible sane behaviour of "git rm $path" might be:
>> 
>>  - If --force is given, remove it from the index and from the
>>    working tree (i.e. "rm -rf $path"), but use the "gitfile"
>>    facility to save $path/.git away to $GIT_DIR/modules/$name; error
>>    out if the submodule directory $path cannot be removed like this.
>>    We would probably want to remove "submodule.<name>.*" entries in
>>    .gitmodules for <name> for which "submodule.<name>.path" matches
>>    the $path.
>> 
>>  - If --cached is given, remove it from the index if the version in
>>    the index match either HEAD or the $path/.git/HEAD, without
>>    touching the working tree.  This is consistent with what happens
>>    to a regular file.
>> 
>>  - If neither --force nor --cached is given, run an equivalent of
>>    (cd $path && git status), and also check if $path/.git/HEAD
>>    matches the index version.  Error out if the submodule directory
>>    is dirty (again I am not sure about this part).  If the submodule
>>    directory is clean, do the same as the case with --force.
>
> What you describe here is exactly how I think "git submodule rm" and
> "git rm --recurse-submodules" should behave.

If you have a directory A with a file B in it (i.e. A/B), "git rm A" is refused and you have to say "git rm -r A". So I can see why the above description of the mine is wrong with respect to "-r" option (all cases should fail if you did not give "-r" option).

But I do not think "git rm" needs "--recurse-submodules". Wasn't "--recurse-submodules" the option to control, when you tell Git to do something to submodule "A", what should happen to submodules contained in the submodule "A" (e.g. "A/B" that appears at path "B" that itself is a separate project bound as a submodule to "A")?

I can see what fetching or updating "A" (e.g. "git submodule update") while leaving "A/B" intact means, so there is a reason to have two ways (with or without --recurse-submodules) to such a command, but I do not see any sensible definition of what it means to "remove" (whether it is "git submodule rm" or just plain "git rm") "A" without affecting "A/B", especially with respect to the working tree files. If you remove "A" and its working tree files, is there a sensible way to keep "A/B" and its working tree files?

I am OK if you choose to implement the behaviour described above only in "git submodule rm A" and not plain "git rm -r A", but if you are going that route, I do not see how it is an improvement for it to remove the index entry for A from the index if your "git rm -r A" does not remove working tree files for submodule A. The user asked to remove A with a command that would remove both index entry and working tree file for a regular file (or a directory), the command may decide it is not prudent to do so for whatever reason. Perhaps the entity being asked to remove has local changes the user may regret losing. Perhaps we decided that such an opration to cause a large structural change should not be done with a plain "rm" but should be done with "git submodule rm". The reasons do not matter much, but for the end result to be consistent, shouldn't the command keep the index entry intact if it does not remove the working tree?

Unless the user used "git rm --cached" to explicitly ask for the index entry to be removed without touching the working tree files, that is.