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:
signature.asc
Description: PGP signature