Simon Tournier <zimon.touto...@gmail.com> writes: > Re, > > On Wed, 02 Apr 2025 at 09:41, 45mg <45mg.wri...@gmail.com> wrote: > >>> every single time I run `guix >>> pull` it appears to do nothing for like 2 minutes, and then the progress >>> bars display as it pulls the entire repo instead of using a cached >>> checkout, which takes forever. > > [...] > > >> `git_remote_fetch` (via the guile-git `remote-fetch` binding). I tested >> this function on the cached clone [1] and it's /extremely/ slow. > > This does not explain what you report above. Being slow once the cached > had been created is somehow “known” – libgit2 corner-cases – but fully > cloning at each “guix pull” is a bug because it should not if > openable-repository? does what it’s expected. :-)
I had /assumed/ it was fully cloning (because of how long it takes), but actually it looks like I was wrong. When "the progress bars display" as I wrote above, the messages associated with them correspond to the `show-progress` function in (guix git), which is passed to `remote-fetch` via `make-default-fetch-options`; this is the only place where it's used. And `remote-fetch` is only called if `guix pull` didn't just do a fresh clone. So it isn't doing a fresh clone after all. As a side note - if I delete ~/.cache/guix/checkouts/, the resulting fresh clone is actually /faster/ than the fetching that happens when the cache exists. If only there was a CLI option to inhibit the caching... > Cheers, > simon
