[bug#65352] Fix time-machine and network

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

As discussed in patch#64746, here the fix. :-)

-------------------- Start of forwarded message --------------------
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Wed, 16 Aug 2023 14:41:55 -0400

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Please note that if git.savannah.gnu.org is not reachable, then “guix
> time-machine” fails.
>
> Let start with the regular:
>
> $ guix describe
> Generation 26   Jul 12 2023 09:13:39    (current)
>   guix 4a027d2
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 4a027d2b0ee68e39f21f6802a8cd1751d3065330
>
> $ guix time-machine --commit=4a027d2 -- describe
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
> building /gnu/store/sg8ca36rlbh4il6jy8dk2gr33lxm4z8q-compute-guix-derivation.drv...
> Computing Guix derivation for 'x86_64-linux'... |
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
> The following derivations will be built:
> [...]
> building profile with 1 package...
>   guix 4a027d2
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     commit: 4a027d2b0ee68e39f21f6802a8cd1751d3065330
>
>
> So far, so good.  Here all is cached and so on.  Now, let make
> git.savannah.gnu.org unreachable by tweaking some stuff.  Then,
>
> $ guix time-machine --commit=4a027d2 -- describe
> guix time-machine: error: Git error: failed to resolve address for git.savannah.gnu.org: Name or service not known

Interesting finding!  I think it'd make sense to raise this issue
separately and discuss its resolution there, too keep things focused and
discoverable :-).
-------------------- End of forwarded message --------------------

The issue is introduced by commit
dce2cf311bc12dee4560329f53ccb53470d5793e in the procedure
reference-available?.  The variable ’ref’ is the pair

    (tag-or-commit . "123abc")

and fails with commit-id? in

  (match ref
    ((or ('commit . commit)
         ('tag-or-commit . (? commit-id? commit)))

Therefore, reference-available? returns #f and the ’when’ branch is run
in update-cached-checkout.

     ;; 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)))

Hence the network access required by remote-fetch.

Well, the heavy work to know if the reference is available or not in the
local checkout is done by ’resolve-reference’ in (guix git) doing all
the cases, and especially dealing with tag-or-commit:

      (match ref
        (('branch . branch)
         (let ((oid (reference-target
                     (branch-lookup repository branch BRANCH-REMOTE))))
           (object-lookup repository oid)))
        (('commit . commit)
         (let ((len (string-length commit)))
           ;; 'object-lookup-prefix' appeared in Guile-Git in Mar. 2018, so we
           ;; can't be sure it's available.  Furthermore, 'string->oid' used to
           ;; read out-of-bounds when passed a string shorter than 40 chars,
           ;; which is why we delay calls to it below.
           (if (< len 40)
               (if (module-defined? (resolve-interface '(git object))
                                    'object-lookup-prefix)
                   (object-lookup-prefix repository (string->oid commit) len)
                   (raise (condition
                           (&message
                            (message "long Git object ID is required")))))
               (object-lookup repository (string->oid commit)))))
        (('tag-or-commit . str)
         (if (or (> (string-length str) 40)
                 (not (string-every char-set:hex-digit str)))
             (resolve `(tag . ,str))              ;definitely a tag
             (catch 'git-error
               (lambda ()
                 (resolve `(tag . ,str)))
               (lambda _
                 ;; There's no such tag, so it must be a commit ID.
                 (resolve `(commit . ,str))))))
        (('tag    . tag)
         (let ((oid (reference-name->oid repository
                                         (string-append "refs/tags/" tag))))
           (object-lookup repository oid))))

Instead of duplicating, I propose to reuse it.  See the trivial first
patch.  I think it fixes the annoyance.

Aside, please note that (guix channels) provide commit-or-tag.  It
change nothing but I would find more consistent to have the same
nomenclature.

--8<---------------cut here---------------start------------->8---
(define (sexp->channel-news-entry entry)
  "Return the <channel-news-entry> record corresponding to ENTRY, an sexp."
  (define (pair language message)
    (cons (symbol->string language) message))

  (match entry
    (('entry ((and (or 'commit 'tag) type) commit-or-tag)
             ('title ((? symbol? title-tags) (? string? titles)) ...)
             ('body ((? symbol? body-tags) (? string? bodies)) ...)
             _ ...)
     (channel-news-entry (and (eq? type 'commit) commit-or-tag)
                         (and (eq? type 'tag) commit-or-tag)
--8<---------------cut here---------------end--------------->8---

WDYT about tag-or-commit everywhere?


Last, as I pointed in a naive comment [1], I do not think that
guix/scripts/pull.scm or guix/time-machine.scm need to support both the
pair (commit . x) and (tag-or-commit . x) because the value ’ref’ is set
by the option.  Hence the second patch.

1: https://yhetil.org/guix/87o7j7f2tb.fsf@gmail.com


Let me know if I am not missing something.


Cheers,
simon