Re: [RFC] git submodule purge

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 26.03.2015 um 14:30 schrieb Patrick Steinhardt:
> On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:
>> Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:
>>> Optionally I could
>>> implement `git gc --purge-submodule=<submodule-name>` as a second
>>> way to access the feature so that we have a way of purging them
>>> without using the submodules-interface. I doubt though that this
>>> will provide much of a benefit as the user still has to be aware
>>> that he is working with submodules as he has to provide the
>>> `--purge-submodule` option, so there is not much to be gained by
>>> this.
>>
>> Hmm, I still believe cleaning up a submodule repo which is already
>> deinited makes sense. Using 'rm -rf .git/modules/<submodulename>'
>> will work just fine, but is missing any safeguards. The deinit
>> command takes submodule paths, not submodule names. So it looks
>> to me like 'git gc --purge-submodule=<submodule-name>' would make
>> sense here (and this command should check that the submodule has
>> already been deinited and fail otherwise telling the user so).
>
> Ah, okay. I thought your intention was to provide `git gc
> --purge-sm` _instead_ of `git sm deinit --purge`. Guess it makes
> sense to have both available for the different use cases
> (explicitly removing a submodule vs removing unreferenced ones).

Yup. And I wonder if `--purge` should be the default for deinit
if no unpushed commits will be lost ... but let's hear what
others think about this one.

> I guess one could even provide another option
> `--purge-submodules` in addition to `--purge-sm=<smname>` that
> will remove all deinitialized submodules without local commits.
> Maybe its desirable to have a `--dry-run` flag as well that would
> print which repositories would be deleted by `--purge-sms`.

Hmm, thinking about that some more maybe we might wanna simplify
this a bit. Adding a `--prune-submodules` option to gc which will
remove all deinitialized submodules repos that don't have any
unpushed commits should be sufficient to do the housekeeping. If
people demand to be able to prune specific submodules later we
could still add a `--prune-submodule=<name>`, but I suspect we
might not need that.