Hipcheck creates local clones of every repository it analyzes, because analyzing a local clone is much faster than trying to work over the network. But some repositories can be quite large, and this cache will currently just continue to grow until the user notices it (ideally before something concerning like running out of disk space) and deletes some of the clones.
We ought to add an hc cache subcommand to manage the cache, probably by:
[ ] Listing repositories in the cache, their head commit, when they were last updated, and their size
[x] Deleting repositories in the cache, either by specifying specific repositories to delete, or doing operations like "delete n oldest" or "delete n largest"
We may also want to enable configuring Hipcheck to alert when the cache directory passes some threshold. For this we probably want a default threshold, and let the user both change the threshold and to turn alerting off entirely. The alerting could take the form of a warning when Hipcheck is run.
Hipcheck creates local clones of every repository it analyzes, because analyzing a local clone is much faster than trying to work over the network. But some repositories can be quite large, and this cache will currently just continue to grow until the user notices it (ideally before something concerning like running out of disk space) and deletes some of the clones.
We ought to add an
hc cache
subcommand to manage the cache, probably by:n
oldest" or "deleten
largest"We may also want to enable configuring Hipcheck to alert when the cache directory passes some threshold. For this we probably want a default threshold, and let the user both change the threshold and to turn alerting off entirely. The alerting could take the form of a warning when Hipcheck is run.