Re: [RFC] git submodule purge

On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:

Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt:

quoted

On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote:

quoted

Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:

[snip]

quoted

quoted

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

quoted

`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.

quoted

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.

quoted

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