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

On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann [off-list ref] wrote:

Am 25.06.2012 22:53, schrieb Phil Hord:

quoted

On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann [off-list ref] wrote:

quoted

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.

I would like to see both supported, eventually. That is, git-rm and
git-submodule-rm should both work.  It would make sense to me when I
am looking for the counterpart to 'git submodule add' to find it under
'git submodule rm', and also under 'git submodule --help'.

Hmm, as long as "git submodule rm" would just use "git rm" under the
hood and not its own scripting that would be ok.

Maybe it would be better if 'git-rm' would use 'git submodule rm'
under the covers.  This would keep the .gitmodules (etc.)
manipulations out of the hair of the git-rm machinery.

Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule.

quoted

quoted

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").

That sounds like a nice next step.  But I would expect that a 'git
[submodule] rm foo' where foo has uncommitted changes to complain to
me (and do nothing else) unless I used --force.  This is similar to
how git-rm already behaves, I think.  And in the case of a dirty
submodule it makes sense to treat the submodule files as an atomic
unit.  That is, if any of the submodule files are dirty and git-rm
will "leave" them, then it should leave the whole submodule.  It would
be very inconvenient to have to restore files back into place at the
correct commit just so I could examine them in context to determine
what I should have done with them before I used git-rm.

We absolutely agree here, this is pretty much what I wrote further
down in my first response ;-)
(except additionally I consider a submodule dirty if it's HEAD isn't
on any branch to avoid loosing commits)

So you did.  What bothered me was the suggestion that you could
partially remove a submodule's files.

quoted

In the special case of a submodule which does not use a gitfile, I am
not even sure if any of the submodule files should be removed. If they
are, what state does that leave the submodule repository in?  A
checked-out workdir whose files are all removed?  'git-status' would
be very noisy in this case.  I'd rather expect this to behave the same
as if I checked out a previous commit which did not have the submodule
added yet.  Today, this leaves the submodule in-place and it shows up
as an untracked file.  I don't know a better way to handle that,
though I expect it would be ok remove all the files even in this case
(if the workdir is not dirty and if the head commit is current in the
superproject).  But it seems extreme to do all of that and then leave
the .git directory lying about in the former submodule directory.

Good point. Another option would be to move the git directory into
.git/modules of the superproject before removing the files, then next
time it's updated it'll use gitfile. But maybe that's a problem which
will go away anyways as all submodules cloned with newer git use
gitfiles anyway.

I like this idea, but it seems a little presumptuous.  The new
behavior might cause a few panicked users to spend the day rebuilding
their "lost" repository.  Maybe we can make this an explicit action.
"git submodule convert-to-gitfile"  :-)

Phil