Jens Lehmann <> writes:

>> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to