Hi, Simon Tournier <zimon.touto...@gmail.com> skribis:
>>> * guix/git.scm (packs-in-git-repository, maybe-run-git-gc): New >>> procedures. >>> (update-cached-checkout): Use it. >>> --- >>> guix/git.scm | 39 ++++++++++++++++++++++++++++++++++++--- >>> 1 file changed, 36 insertions(+), 3 deletions(-) > > LGTM. Thanks! > Just two colors for the bikeshed. :-) > > >>> + (when (> (packs-in-git-repository directory) 25) > > Why 25? And not 10 or 50 or 100? Totally arbitrary. :-) I sampled the checkouts I had on my laptop and that seems like a reasonable heuristic. In particular, it seems that Git-managed checkouts never have this many packs; only libgit2-managed checkouts do, precisely because libgit2 doesn’t repack/GC. >>> + ;; Run 'git gc' if needed. >>> + (maybe-run-git-gc cache-directory) > > Why not trigger it by “guix gc”? Because so far the idea is that ~/.cache/guix/checkouts is automatically managed without user intervention; it’s really a cache in that sense. > Well, I expect “guix gc” to take some time and I choose when. However, > I want “guix pull” or “guix time-machine” to be as fast as possible and > here some extra time is added, and I cannot control exactly when. Yes, I see. The thing is ‘maybe-run-git-gc’ is only called on the slow path; so for example, it’s not called on a ‘time-machine’ cache hit, but only on a cache miss, which is already expensive anyway. Does that make sense? Thanks, Ludo’.
