[RFC] git submodule purge

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

Hi,

This proposal is just for discussion. If there is any interest I
will implement the feature and send some patches.


Currently it is hard to properly remove submodules. That is when
a submodule is deinitialized and removed from a repository the
directory '.git/modules/<SM_NAME>' will still be present and
there is no way to remove it despite manually calling `rm` on it.
I think there should be a command that is able to remove those
dangling repositories if the following conditions are met:

- the submodule should not be initialized

- the submodule should not have an entry in .gitmodules in the
  currently checked out revision

- the submodule should not contain any commits that are not
  upstream

- the submodule should not contain other submodules that do not
  meet those conditions

This would ensure that it is hard to loose any commits that may
be of interest. In the case that the user knows what he is doing
we may provide a '--force' switch to override those checks.

What is problematic, though, is when there are multiple branches
under active development where one branch contains a submodule
and another one does not. Given the checks listed above, though,
an accidentally removed submodule repository should not prove
problematic as it should be possible to easily re-clone it. It
might just be cumbersome if the user accidentally removes a
submodule and has to re-initialize it after switching branches.

Regarding behavior of the command I thought about something like
`git submodule purge (<SM_NAME>|<DIRECTORY>|-a)` where 'SM_NAME'
would remove the given submodule, 'DIRECTORY' would remove all
submodules under a certain directory and '-a' would remove all
submodules that are currently inactive. It might be useful to
provide a '--dry-run' switch that lists all submodules that would
be removed without actually removing them.

Some questions that arise here:

- should those actions be recursive? E.g. if a submodule contains
  submodules itself, should those be deleted (after the
  conditions are met), as well?

- should the user be asked for consent for every submodule that
  is about to be deleted or do we assume that he knows what he is
  doing?


Some feedback on this would be appreciated.

Regards
Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]