Re: [PATCH 2/2] git-submodule: support 'rm' command.

On Mon, 25 Jun 2012 18:58:36 +0200
Jens Lehmann [off-list ref] wrote:

Am 25.06.2012 12:57, schrieb Michał Górny:

quoted

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

My main intent was, like Phil already pointed out, to provide
a counterpart to 'git submodule add'. I don't mind 'git rm' supporting
removing submodules but that's not exactly what I would consider...
friendly?

What I'm trying to express is that if I added a submodule using 'git
submodule add', I would expect to have 'git submodule rm'. Honestly, I
didn't even think about trying using 'git rm' on a submodule.
The correct results of such a call are hard to predict to me.

Also it shouldn't be necessary for the user to remove the directory
by hand before running "git rm". At least all files recorded in the
submodule can be removed (and if the submodule uses a gitfile that
can be removed too). Then all that is left are untracked files the
user has to decide what to do with (which might be removed too when
running "git rm --recurse-submodules=untracked").

Except for the untracked files there may also be commits which were not
pushed anywhere. Honestly, I didn't want to get into that risky area in
the first patch.

As the next step, I'd see adding a '--force' option to actually enforce
removing the directory. But I'd like the basics to start working first,
then consider harder things.

quoted

++
+This command removes the submodule from the current git index,
+the .gitmodules file and the local repository config.

It should not be removed from .git/config by default. The user may
have special settings there and the presence in .git/config shows
he cared about having the submodule checked out, which should not
be revoked by just removing the submodule from the work tree.
Unless he removes the config from there himself he should get back
a populated submodule when he checks out an earlier commit and says
"git submodule update".

Ok, I will change that.

-- 
Best regards,
Michał Górny