bug#65787: time-machine is doing too much network requests

["Ludovic Courtès" <ludo@gnu.org>]

Hello Simon,

This is a long message; I agree with the intent (avoiding network
traffic when the required commit is already in cache), but I’m not sure
about the analysis.  It would probably be easier if you could come with
an example where there’s Git-related network traffic where there
shouldn’t.

Let me give some perspective on what the code intends to do.

‘cached-channel-instance’ has 3 cases:

  1. Obvious cache hit: This is when CHANNELS specifies the commit of
     each target channel (this happens for example when you type ‘guix
     time-machine -q --commit=a4c35c607cfd7d6b0bad90cfcc46188d489e1754)
     *and* the combination of channels is already in
     ~/.cache/guix/inferiors.  This is the optimal case: the Git repo
     doesn’t even need to be opened.

  2. Cache hit: CHANNELS are pinned, but refer to tags (like “v1.2.0”)
     or short commit IDs (like “a4c35c6”).  In that case,
     ‘channel-full-commit’ opens the Git repo to resolve the identifier.
     After that, we go to case #1 or #4.

  3. Cache hit: CHANNELS are not pinned—i.e., they refer to a branch,
     not a commit.  In that case we first need to perform a ‘git fetch’
     and then we go to #1 or #4.

  4. Cache miss: ‘reference-available?’ returns #f for the channel
     commits, we got through ‘remote-fetch’ followed by
     ‘build-derivations’.

As with all caches, what matters is to make sure case #1 is processes as
efficiently as possible.  I believe it’s the case since the Git repo is
not even opened.

Of course it would be nice to speed up #2 and #3 too (as long as it’s
not at the expense of #1).  Maybe this is the purpose of your message:
reducing Git remote accesses in those cases?  (Apologies, I just
realized this might have been what you had in mind.  :-))

Thanks,
Ludo’.