Re: [RFC] git submodule purge

[Patrick Steinhardt <ps@pks.im>]

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

On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:
> Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:
> > On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote:
> >> Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:
[snip]
> >> Hmm, cmd_deinit() seems to cope with submodules removed by the
> >> user just fine (as long as they are still present in the index).
> >> To me it feels natural to extend deinit to remove the repo from
> >> .git/modules too when --purge is given (as long as no unpushed
> >> commits are present or -f is given).
> >>
> >>> `git gc` feels saner in that regard, but I don't think it would
> >>> be easy to spot for users as this command is in general not used
> >>> very frequently by them. One could argue though that it does not
> >>> need to be discoverable.
> >>
> >> The error message of "git submodule deinit --purge" for a
> >> submodule that isn't recorded in the index anymore could point
> >> the user to the appropriate gc command. But how do we tell gc
> >> which submodule it should purge? "--purge=<submodule-name>"
> >> maybe?
> >
> > This might work, but at least the option would need to provide a
> > hint to the user that it has something to do with submodules. So
> > if the feature was implemented by `git gc` I'd rather name the
> > parameter "--purge-submodule=<submodule-name>" which in my
> > opinion clearly states its intention, even though it is longer to
> > type. But with working bash-completion this should be non-issue,
> > especially as this command would not need to be run frequently.
> 
> Agreed.
> 
> > That said, I think by now I agree with the common (?) opinion
> > that the command is best placed in `git submodule deinit --purge`
> > and I will likely implement it there.
> 
> Me thinks that makes sense. But be aware that this will only work
> for those submodules that are still present in the current index.
> 
> > 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).
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`.


Patrick

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