From: "Ludovic Courtès" <ludo@gnu.org>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: Josselin Poiret <dev@jpoiret.xyz>,
Christopher Baines <mail@cbaines.net>,
65720@debbugs.gnu.org, 66650@debbugs.gnu.org
Subject: [bug#66650] bug#65720: [bug#66650] [PATCH] git: Shell out to ‘git gc’ when necessary.
Date: Thu, 16 Nov 2023 13:12:22 +0100 [thread overview]
Message-ID: <87h6ll28yh.fsf@gnu.org> (raw)
In-Reply-To: <87v8a4el3a.fsf@gmail.com> (Simon Tournier's message of "Tue, 14 Nov 2023 10:32:41 +0100")
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’.
next prev parent reply other threads:[~2023-11-16 12:35 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-03 20:44 bug#65720: Guile-Git-managed checkouts grow way too much Ludovic Courtès
2023-09-04 21:47 ` Ludovic Courtès
2023-09-05 8:18 ` Josselin Poiret via Bug reports for GNU Guix
2023-09-05 14:18 ` Ludovic Courtès
2023-09-06 8:04 ` Josselin Poiret via Bug reports for GNU Guix
2023-09-08 17:08 ` Ludovic Courtès
2023-09-11 7:00 ` Csepp
2023-09-11 8:42 ` bug#65720: Digression about Git implementations (was Re: bug#65720: Guile-Git-managed checkouts grow way too much) Simon Tournier
2023-09-11 14:42 ` bug#65720: Guile-Git-managed checkouts grow way too much wolf
2023-09-13 18:10 ` Ludovic Courtès
2023-09-13 22:36 ` Simon Tournier
2023-09-07 0:41 ` Simon Tournier
2023-09-08 17:09 ` Ludovic Courtès
2023-09-09 10:31 ` Simon Tournier
2023-09-11 7:06 ` Csepp
2023-09-11 14:37 ` Ludovic Courtès
2023-10-20 16:15 ` bug#65720: [PATCH] git: Shell out to ‘git gc’ when necessary Ludovic Courtès
2023-10-23 10:08 ` Simon Tournier
2023-10-23 22:27 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2023-10-23 23:28 ` bug#65720: Guile-Git-managed checkouts grow way too much Simon Tournier
2023-10-30 12:02 ` bug#65720: [bug#66650] [PATCH] git: Shell out to ‘git gc’ when necessary Christopher Baines
2023-11-14 9:19 ` Ludovic Courtès
2023-11-14 9:32 ` Simon Tournier
2023-11-16 12:12 ` Ludovic Courtès [this message]
2023-11-16 13:24 ` [bug#66650] " Simon Tournier
2023-11-22 11:17 ` bug#65720: " Ludovic Courtès
2023-11-22 11:57 ` [bug#66650] bug#65720: Guile-Git-managed checkouts grow way too much Simon Tournier
2023-11-22 11:57 ` Simon Tournier
2023-11-22 16:00 ` bug#66650: " Ludovic Courtès
2023-09-05 8:22 ` Jelle Licht
2023-09-05 14:20 ` Ludovic Courtès
2023-09-05 18:59 ` Simon Tournier
2023-09-05 14:11 ` Ludovic Courtès
2023-09-18 22:35 ` Ludovic Courtès
2023-09-19 7:19 ` Simon Tournier
2023-11-23 11:35 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6ll28yh.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=65720@debbugs.gnu.org \
--cc=66650@debbugs.gnu.org \
--cc=dev@jpoiret.xyz \
--cc=mail@cbaines.net \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.