Hi, On Wed, 02 Apr 2025 at 09:01, 45mg <45mg.wri...@gmail.com> wrote:
>> 1) Actual 'git pull' equivalent. >> >> 2) The 'guix authenticate' dance on the commits. >> >> 3) The Guix derivation part. >> >> In some settings, I fear step 1 and 2 takes comparable time as 3. > > In my experience, authentication is pretty fast. `guix git authenticate` > processes hundreds of commits in under a second. Yes. Although it could be a bit improved – see [1] – that’s not the main bottleneck, from my experience too. Somehow, #2 is far to be comparable from #1 and #3. Again, from my experience. > The initial `git pull` part can be surprisingly slow, though. And it's > not always a network thing. For example, 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. Yes, that’s what I was meaning when mentioning bug#65787 [2]. Somehow, it’s kind of “network inefficiencies”. It does not necessarily come from the performance of the network link itself but it comes from poor management of the network, IMHO. However, what you describe seems more a bug. If you run once “guix pull”, then it will take forever to “git clone”. The next “guix pull” should be fast since it only does either “git pull” (or “git checkout” when you run “guix pull --commit=123abc” and 123abc is already part of the cache repository). Could you share the output of --8<---------------cut here---------------start------------->8--- scheme@(guix-user)> ,use(git) scheme@(guix-user)> ,use(guix git) scheme@(guix-user)> (define url "https://git.savannah.gnu.org/git/guix.git";) scheme@(guix-user)> (define cache-directory (url-cache-directory url (%repository-cache-directory))) scheme@(guix-user)> (openable-repository? cache-directory) $1 = #t scheme@(guix-user)> cache-directory $2 = "/home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq" --8<---------------cut here---------------end--------------->8--- ? I guess, openable-repository? returns #f instead of #t, right? Well, I think the issue is from update-cached-checkout in (guix git)… # > It's probably a bug with the caching; I pull from a local authenticated > fork, which can't be too common, so it makes sense that this hasn't been > caught before. I haven't had time to properly debug it yet (deleting the > cache does not help). …and something along: (let* ((cache-exists? (openable-repository? cache-directory)) (repository (if cache-exists? (repository-open cache-directory) (clone/swh-fallback url ref cache-directory #:verify-certificate? verify-certificate?)))) ;; Only fetch remote if it has not been cloned just before. (when (and cache-exists? (not (reference-available? repository ref))) (remote-fetch (remote-lookup repository "origin") #:fetch-options (make-default-fetch-options #:verify-certificate? verify-certificate?))) Therefore, that’s why my guess is about openable-repository? Cheers, simon 1: comparing commit-relation using Scheme+libgit2 vs shellout plumbing Git Simon Tournier <zimon.touto...@gmail.com> Tue, 12 Sep 2023 00:48:30 +0200 id:865y4gz5q9....@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-09 https://yhetil.org/guix/865y4gz5q9....@gmail.com 2: bug#65787: time-machine is doing too much network requests Simon Tournier <zimon.touto...@gmail.com> Wed, 06 Sep 2023 18:26:18 +0200 id:87wmx3mfo5....@gmail.com https://issues.guix.gnu.org/65787 https://issues.guix.gnu.org/msgid/87wmx3mfo5....@gmail.com https://yhetil.org/guix/87wmx3mfo5....@gmail.com
