Re: [RFC] git submodule purge
From: Jens Lehmann <hidden>
Date: 2016-06-15 23:04:18
Am 26.03.2015 um 14:30 schrieb Patrick Steinhardt:
On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote:quoted
Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt: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).
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.