[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65720: [bug#66650] [PATCH] git: Shell out to ‘git gc’ when necessary
From: |
Ludovic Courtès |
Subject: |
bug#65720: [bug#66650] [PATCH] git: Shell out to ‘git gc’ when necessary. |
Date: |
Thu, 16 Nov 2023 13:12:22 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi,
Simon Tournier <zimon.toutoune@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’.