guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#65352] Fix time-machine and network


From: Maxim Cournoyer
Subject: [bug#65352] Fix time-machine and network
Date: Tue, 05 Sep 2023 22:00:11 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

reopen 65352
quit

Hi Simon,

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

> Hi Maxim,
>
> On Wed, 6 Sept 2023 at 02:04, Maxim Cournoyer <maxim.cournoyer@gmail.com> 
> wrote:
>
>> I had indeed missed its continuation!  I've reverted a789dd5865 with
>> 756e336fa0 and installed c3d48d024, which should now validate the
>> branch/commit of a channel file as well.
>
> Thanks for the follow up.
>
> The other issue about the order of the progress bar and the message
> "Updating guix ..." is not yet fixed. :-) I am fine to open another
> issue for that but since it appears to me the same patch series as
> this one.  Well you are applying patches faster than I am able to
> process my emails or comment your messages. ;-)  Anyway, I will open a
> report for that order issue.

OK, thank you.  It's a bit hard to keep track of multiple issues and
their resolutions in a longish thread.

> However, this bug #65352 is not done.
>
>     https://issues.guix.gnu.org/65352#0
>
> The bug I report is, for instance, consider "guix time-machine
> --commit=v1.4.0", this will pass (tag-or-commit . "v1.4.0") as REF to
> reference-available? which is not a commit-id? if I read correctly.
> And so reference-available? will return #f triggered an network update
> when the reference if already in the cache checkout.

I don't know if we want to consider tags are immutable or not; the
safest is to consider them an *not* immutable, which is what we had been
doing.  I agree it doesn't cover all the potential git refspecs; we can
get there if we want (although I suppose it's uncommon for someone to
try 'guix time-machine --commit=v1.3.0-47405-ge0767a24d0' or similar).

> It is similar with short commit hash as "guix time-machine
> --commit=4a027d2".  That's what I reported.

I'm not sure if short commit IDs should be treated as immutable, since
in theory they can collide; the safest would be to check if there are
collisions and report an error if there is; and this requires fetching
new objects first.

So, what is the behavior that we want?

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]