Hi, On Mon, 04 Sep 2023 at 23:47, Ludovic Courtès <l...@gnu.org> wrote:
>> It would seem that libgit2 doesn’t do the equivalent of ‘git gc’. > > Confirmed: <https://github.com/libgit2/libgit2/issues/3247>. Ouch! The goals of the project haven't changed, and neither have the tradeoffs. If one were to rewrite git-gc on top of libgit2, the best-case scenario is ending up with what we already had. If you want to use regular maintenance on some repostories, use git gc, that's what it's there for. https://github.com/libgit2/libgit2/issues/3247#issuecomment-152508040 > My inclination for the short term would be to work around this > limitation by (1) finding a heuristic to determine is a checkout has > likely accumulated too much cruft, and (2) considering such checkouts > as expired (thereby forcing a re-clone) or running ‘git gc’ on them if > ‘git’ is available. About (1) maybe we could add a “counter” and teach after X updates of the checkout then let run (2). Well, I guess the number of crufts is more or less proportional with the number of checkout updates; that’s the heuristic I would use. The most annoying is (2). Because forcing a re-clone does not appear to me a solution; I prefer to waste disk space (and probably run myself and manually ‘git gc’) than re-clone… Somehow this re-clone would always happen when I am using a poor network. Moreover, assuming this clean-up (2) would be run once every while, we could imagine to invoke something like, guix shell -C git-minimal -- git -C ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq gc when the checkout is updated. And maybe we could provide another “guix pull” command-line option for turning off this and mark it as done (reset the “counter”). Well, that’s a poor solution but we can assume that git-minimal is at worse available using “guix shell git-minimal”. Note that the closure of git-minimal is far less than re-cloning the full Guix repository. Cheers, simon