Re: [RFC] git submodule purge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]