Downgrade prevention triggers erroneously with 'guix pull'

Open

Details

6 participants

45mg
Jack Hill
Leo Famulari
Ludovic Courtès
Simon Tournier
Tomas Volf

Owner: unassigned

Submitted by: Jack Hill

Severity: important

Debbugs page

Jack Hill wrote on 1 Mar 08:37 -0800

current guix pull doesn't authenticate

Recipients:(address . bug-guix@gnu.org)

Message-ID:alpine.DEB.2.21.2503011134420.24671@marsh.hcoop.net

jackhill@lissome ~$ guix describe
Generation 159  Feb 27 2025 22:08:27    (current)
   guix f13f076
     repository URL: https://git.savannah.gnu.org/git/guix.git
     branch: master
     commit: f13f0769688493271f43f31a016957355dbecb30
jackhill@lissome ~$ guix pull
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: aborting update of channel 'guix' to commit 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of f13f0769688493271f43f31a016957355dbecb30
hint: This could indicate that the channel has been tampered with and is trying to force a
roll-back, preventing you from getting the latest updates.  If you think this is not the
case, explicitly allow non-forward updates.

I don't have reason to believe the channel needs to be rolled back, I 
assume something is wrong with the savannah copy of the repo, but don't 
know. Can someone confirm?

Thanks!
Jack

Tomas Volf wrote on 1 Mar 13:41 -0800

Recipients:(name . Jack Hill)(address . jackhill@jackhill.us)(address . 76660@debbugs.gnu.org)

Message-ID:87y0xoo2df.fsf@wolfsden.cz

Jack Hill <jackhill@jackhill.us> writes:

Toggle quote (17 lines)> jackhill@lissome ~$ guix describe
> Generation 159  Feb 27 2025 22:08:27    (current)
>   guix f13f076
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: f13f0769688493271f43f31a016957355dbecb30
> jackhill@lissome ~$ guix pull
> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
> guix pull: error: aborting update of channel 'guix' to commit 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of f13f0769688493271f43f31a016957355dbecb30
> hint: This could indicate that the channel has been tampered with and is trying to force a
> roll-back, preventing you from getting the latest updates.  If you think this is not the
> case, explicitly allow non-forward updates.
>
> I don't have reason to believe the channel needs to be rolled back, I assume
> something is wrong with the savannah copy of the repo, but don't know. Can
> someone confirm?

Can confirm.

Toggle snippet (12 lines)

/tmp/test$ /tmp/test/profile/bin/guix describe

Generation 1 Mar 01 2025 21:04:08 (current)

guix f13f076

repository URL: https://git.savannah.gnu.org/git/guix.git

commit: f13f0769688493271f43f31a016957355dbecb30

/tmp/test$ /tmp/test/profile/bin/guix pull -q --commit=6ca7b07a251739dfaefa639e74c01e3013c9454c --profile=/tmp/test/profile

Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...

guix pull: error: aborting update of channel 'guix' to commit 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of f13f0769688493271f43f31a016957355dbecb30

hint: Use `--allow-downgrades' to force this downgrade.

There is nothing wrong with the repository, and the commit is a

descendant:

Toggle snippet (5 lines)

$ git merge-base --is-ancestor f13f0769688493271f43f31a016957355dbecb30 6ca7b07a251739dfaefa639e74c01e3013c9454c

$ echo $?

Given that f13f0769688493271f43f31a016957355dbecb30 has fairly large
commit message, maybe the known bugs in how we are using guile-git
finally caught up with us.

I guess you can use the --allow-downgrades to by-pass the check after
you manually verify in the git repository the relation of the commits.
Sucks, but should allow you to pull.

Have a nice day,
Tomas
-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

45mg wrote on 1 Mar 22:24 -0800

Recipients:(address . 76660@debbugs.gnu.org)

Message-ID:877c58q79k.fsf@gmail.com

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (1 lines)

> Jack Hill <jackhill@jackhill.us> writes:

[...]

Toggle quote (12 lines)>> jackhill@lissome ~$ guix pull
>> Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
>> guix pull: error: aborting update of channel 'guix' to commit 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of f13f0769688493271f43f31a016957355dbecb30
>> hint: This could indicate that the channel has been tampered with and is trying to force a
>> roll-back, preventing you from getting the latest updates.  If you think this is not the
>> case, explicitly allow non-forward updates.
>>
>> I don't have reason to believe the channel needs to be rolled back, I assume
>> something is wrong with the savannah copy of the repo, but don't know. Can
>> someone confirm?
>
> Can confirm.

[...]

Toggle quote (4 lines)

> Given that f13f0769688493271f43f31a016957355dbecb30 has fairly large

> commit message, maybe the known bugs in how we are using guile-git

> finally caught up with us.

I just re-authenticated my existing checkout of Guix from scratch (`rm

-r ~/.cache/guix/authentication/* && guix git authenticate`), and the

authentication was successful. (The checkout is up-to-date, as both

6ca7b07a251739dfaefa639e74c01e3013c9454c and

f13f0769688493271f43f31a016957355dbecb30 can be found in `git log`.)

However, I have not yet pulled 6ca7b07a251739dfaefa639e74c01e3013c9454c.

I'm currently on b9063be5a73114c1bfb23121b7c9b612835d014d [1].

So, I think you're right - it's probably an issue in `guix pull` or the

authentication mechanism, not the Guix repository (assuming that others

can also reproduce this).

[1] ...well, technically, I'm pulling from a personal authenticated fork

where upstream commits are rebased onto the branch I pull from; so

the hashes are all different even though the commit contents are all

the same. So I'm not actually on

b9063be5a73114c1bfb23121b7c9b612835d014d; rather, that's the last

commit that I rebased onto my fork branch.

Leo Famulari wrote on 2 Mar 10:50 -0800

Recipients:(name . Jack Hill)(address . jackhill@jackhill.us)(address . 76660@debbugs.gnu.org)

Message-ID:Z8Sog2wmaP2rT0IT@jasmine.lan

On Sat, Mar 01, 2025 at 11:37:40AM -0500, Jack Hill wrote:

Toggle quote (5 lines)

> guix pull: error: aborting update of channel 'guix' to commit 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of f13f0769688493271f43f31a016957355dbecb30

> hint: This could indicate that the channel has been tampered with and is trying to force a

> roll-back, preventing you from getting the latest updates. If you think this is not the

> case, explicitly allow non-forward updates.

I successfully pulled from the latest commit on the 'master' branch:

------

$ guix package -p ~/.config/guix/current -l

[...]

Generation 242 Mar 02 2025 13:45:23 (current)

+ nonguix 45bde19 out /gnu/store/ahqhr9qbhq9w83fl3yif8qy5vfkhay7c-nonguix

+ guix 56a374a out /gnu/store/lfwph6c7099c0f5dzfpffg1qm93va5iv-guix-56a374aa7

- nonguix 87c5b72 out /gnu/store/1kbmg93s0sc3ic01pql1jic6nr8mzkhi-nonguix

- guix 55a5181 out /gnu/store/vc2sn17c6g7ww4akd7p9dcfby6zykr81-guix-55a5181e7

------

This commit is a descendant of both of the commits from your error

message.

And `guix git authenticate` succeeds from 56a374a as well.

So what's going on?

Tomas Volf wrote on 2 Mar 11:08 -0800

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:87mse3jlml.fsf@wolfsden.cz

Leo Famulari <leo@famulari.name> writes:

Toggle quote (8 lines)

> On Sat, Mar 01, 2025 at 11:37:40AM -0500, Jack Hill wrote:

>> guix pull: error: aborting update of channel 'guix' to commit 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of f13f0769688493271f43f31a016957355dbecb30

>> hint: This could indicate that the channel has been tampered with and is trying to force a

>> roll-back, preventing you from getting the latest updates. If you think this is not the

>> case, explicitly allow non-forward updates.

> I successfully pulled from the latest commit on the 'master' branch:

Can you pull *any* commit from 6ca7b07a251739dfaefa639e74c01e3013c9454c?

I have just tried:

Toggle snippet (12 lines)$ /tmp/test/profile/bin/guix describe
Generation 1	Mar 01 2025 21:04:08	(current)
  guix f13f076
    repository URL: https://git.savannah.gnu.org/git/guix.git
    commit: f13f0769688493271f43f31a016957355dbecb30
$ /tmp/test/profile/bin/guix pull -q --profile=/tmp/test/profile
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: aborting update of channel 'guix' to commit 56a374aa79fd93a90373417b9a33b27dda633449, which is not a descendant of f13f0769688493271f43f31a016957355dbecb30
hint: This could indicate that the channel has been tampered with and is trying to force a roll-back, preventing you from getting the latest updates.  If you think this is not the case,
explicitly allow non-forward updates.

So it does not work for 56a374aa79fd93a90373417b9a33b27dda633449

(current master) on my machine. Out of curiosity, can you try to pull

current master, but from 6ca7b07a251739dfaefa639e74c01e3013c9454c?

Toggle quote (18 lines)>
> ------
> $ guix package -p ~/.config/guix/current -l
> [...]
> Generation 242	Mar 02 2025 13:45:23	(current)
>  + nonguix	45bde19	out	/gnu/store/ahqhr9qbhq9w83fl3yif8qy5vfkhay7c-nonguix
>  + guix   	56a374a	out	/gnu/store/lfwph6c7099c0f5dzfpffg1qm93va5iv-guix-56a374aa7
>  - nonguix	87c5b72	out	/gnu/store/1kbmg93s0sc3ic01pql1jic6nr8mzkhi-nonguix
>  - guix   	55a5181	out	/gnu/store/vc2sn17c6g7ww4akd7p9dcfby6zykr81-guix-55a5181e7
> ------
>
> This commit is a descendant of both of the commits from your error
> message.
>
> And `guix git authenticate` succeeds from 56a374a as well.
>
> So what's going on?

Possible explanation would be that there is a bug in the descendancy
detection when your current Guix is on specific commits (my guesstimate
would be the trigger is having large commit message, I have reported
this issue before).

Have a nice day,
Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Leo Famulari wrote on 2 Mar 14:47 -0800

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)

Message-ID:Z8TgDzBDgv5UPBUJ@jasmine.lan

On Sun, Mar 02, 2025 at 08:08:50PM +0100, Tomas Volf wrote:

Toggle quote (5 lines)

> Possible explanation would be that there is a bug in the descendancy

> detection when your current Guix is on specific commits (my guesstimate

> would be the trigger is having large commit message, I have reported

> this issue before).

Can you share these prior reports here?

Leo Famulari wrote on 2 Mar 15:39 -0800

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)

Message-ID:Z8TsS1f-Q4n7B5tR@jasmine.lan

On Sun, Mar 02, 2025 at 08:08:50PM +0100, Tomas Volf wrote:

Toggle quote (2 lines)

> Can you pull *any* commit from 6ca7b07a251739dfaefa639e74c01e3013c9454c?

Yes:

------
$ guix package -p ~/.config/guix/current -l
[...]
Generation 242	Mar 02 2025 18:24:39
 + guix   	6ca7b07	out	/gnu/store/3bp49nygmmfq340fcgwpslryvqlbmlm9-guix-6ca7b07a2
 - nonguix	87c5b72	out	/gnu/store/1kbmg93s0sc3ic01pql1jic6nr8mzkhi-nonguix
 - guix   	55a5181	out	/gnu/store/vc2sn17c6g7ww4akd7p9dcfby6zykr81-guix-55a5181e7

Generation 243	Mar 02 2025 18:31:47	(current)
 + guix	08bf8d1	out	/gnu/store/0xp5zrr6ii0xwpy0md4bgxqaprijmh47-guix-08bf8d175
 - guix	6ca7b07	out	/gnu/store/3bp49nygmmfq340fcgwpslryvqlbmlm9-guix-6ca7b07a2
------

I did notice that I was unable to pull from 6ca7b07 along with nonguix.
In that case the package-cache failed to build like this:

------
[...]
building package cache...
(repl-version 0 1 1)
Generating package cache for '/gnu/store/b4f6r9wn4wc6mvw2fv6vbm2kz1gpxmgx-profile'...

Backtrace:
In guix/repl.scm:
    141:4 19 (machine-repl _ _)
    126:7 18 (_)
In ice-9/boot-9.scm:
  1747:15 17 (with-exception-handler #<procedure 7fffefeff3f0 at ic…> …)
  1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In guix/repl.scm:
    99:21 15 (_)
In unknown file:
          14 (_ #<procedure 7ffff4ab11e0 at guix/repl.scm:100:25 ()> …)
          13 (primitive-load "/gnu/store/3myfgdm742h3r3g3xl4fay58g0a…")
In ice-9/boot-9.scm:
  1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In gnu/packages.scm:
   465:11 11 (generate-package-cache _)
In srfi/srfi-1.scm:
   460:18 10 (fold #<procedure expand-cache expr> _ _)
In gnu/packages.scm:
   425:37  9 (expand-cache . _)
In guix/packages.scm:
  1444:17  8 (supported-package? #<package dotnet@3.1.419 nongnu/pa…> …)
In guix/memoization.scm:
    101:0  7 (_ #<hash-table 7fffe09093a0 9870/14051> #<package dot…> …)
In guix/packages.scm:
  1422:39  6 (_)
  1692:16  5 (package->bag _ _ _ #:graft? _)
  1793:48  4 (thunk)
In nongnu/packages/dotnet.scm:
   290:19  3 (inputs #<package dotnet@3.1.419 nongnu/packages/dotnet…>)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1780:13  1 (_ #<&compound-exception components: (#<&undefined-vari…>)
In unknown file:
           0 (backtrace #<undefined>)

(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (icu4c-71)) (value #f))
builder for `/gnu/store/m5jxnijhnkhz2y8210l67g0f9azlqm2n-guix-package-cache.drv' failed to produce output path `/gnu/store/s91dv1ihqdvavmykxialqvgifjfvsl8z-guix-package-cache'
build of /gnu/store/m5jxnijhnkhz2y8210l67g0f9azlqm2n-guix-package-cache.drv failed
hint: This usually indicates a bug in one of the channels you are pulling from, or some incompatibility among them.  You can check the build log and report the issue to the channel developers.

The channels you are pulling from are: nonguix guix.
------

Tomas Volf wrote on 2 Mar 15:44 -0800

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:875xkrj8vg.fsf@wolfsden.cz

Leo Famulari <leo@famulari.name> writes:

Toggle quote (8 lines)

> On Sun, Mar 02, 2025 at 08:08:50PM +0100, Tomas Volf wrote:

>> Possible explanation would be that there is a bug in the descendancy

>> detection when your current Guix is on specific commits (my guesstimate

>> would be the trigger is having large commit message, I have reported

>> this issue before).

> Can you share these prior reports here?

I expect the root cause to be the same as in 66268. (Man, is it over an

year already? The time sure does fly.)

I assume this[0] commit from my fork should fix the issue, does not

apply cleanly (should be trivial to adjust). The current way to compare

commits from guile-git (eq?) is simply wrong.

Tomas

0: https://git.wolfsden.cz/guix/commit/?id=2e52fbc6fed667f938db1d743e279e3f4a1a1658

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

Jack Hill wrote on 7 Mar 19:16 -0800

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)

Message-ID:alpine.DEB.2.21.2503072212540.24671@marsh.hcoop.net

Assuming I understand correctly that there's no way to get this commit to

verify: what are the next steps?

Future looking, we should apply the patch so that we don't get

non-verifiable commits in the future, but that won't help me, since I'll

have to verify it with my current guix.

How can I reset my state and move forward in a safe way? I assume it

involves some manually verifying of commits?

I'm afraid I don't understand why only some people run into this problem.

Thanks!

Jack

Tomas Volf wrote on 9 Mar 01:33 -0800

Recipients:(name . Jack Hill)(address . jackhill@jackhill.us)

Message-ID:87ldtezgxy.fsf@wolfsden.cz

Jack Hill <jackhill@jackhill.us> writes:

Toggle quote (10 lines)> Assuming I understand correctly that there's no way to get this commit to
> verify: what are the next steps?
>
> Future looking, we should apply the patch so that we don't get non-verifiable
> commits in the future, but that won't help me, since I'll have to verify it with
> my current guix.
>
> How can I reset my state and move forward in a safe way? I assume it involves
> some manually verifying of commits?

I see few options:

1. Revert to previous good state using `guix pull --roll-back', and try

pulling again. Maybe it will help.

2. Checkout the Guix repository, switch to the last commit known to you

to be safe, patch the guix/git.scm file ([0] should now apply

clearly), build the modified Guix locally and pull using it.

3. Take someones word that some specific new commit is safe, and just

pull while disabling protections. Statistically, if few people

independently confirm the commit on IRC, if should be pretty safe.

Number 1 is probably quickest to just try. :)

Toggle quote (4 lines)

> I'm afraid I don't understand why only some people run into this

> problem.

I think it could be influenced by the commit you are currently on, and

the commit you are pulling as latest. So depending on time of previous

and current pull, it might work or it might not work. I assume that

limits the amount of affected people.

Toggle quote (5 lines)

> Thanks!

> Jack

0: https://git.wolfsden.cz/guix/tree/etc/0001-git-Fix-usage-of-guile-git.patch

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

Leo Famulari wrote on 9 Mar 14:31 -0700

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)

Message-ID:Z84IoyZfmIiwBq9n@jasmine.lan

On Sun, Mar 09, 2025 at 10:33:45AM +0100, Tomas Volf wrote:

Toggle quote (5 lines)

> I think it could be influenced by the commit you are currently on, and

> the commit you are pulling as latest. So depending on time of previous

> and current pull, it might work or it might not work. I assume that

> limits the amount of affected people.

Yes, it might or might not work. Some of us can pull from the "bad

commit", and some of us can't:

https://issues.guix.gnu.org/76660#6

So, either we don't understand all the conditions that trigger this bug,

or it's not deterministic. But we should work to get the fix into

guile-git.

Tomas Volf wrote on 9 Mar 16:38 -0700

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:871pv5zser.fsf@wolfsden.cz

Leo Famulari <leo@famulari.name> writes:

Toggle quote (15 lines)> On Sun, Mar 09, 2025 at 10:33:45AM +0100, Tomas Volf wrote:
>> I think it could be influenced by the commit you are currently on, and
>> the commit you are pulling as latest.  So depending on time of previous
>> and current pull, it might work or it might not work.  I assume that
>> limits the amount of affected people.
>
> Yes, it might or might not work. Some of us can pull from the "bad
> commit", and some of us can't:
>
> https://issues.guix.gnu.org/76660#6
>
> So, either we don't understand all the conditions that trigger this bug,
> or it's not deterministic. But we should work to get the fix into
> guile-git.

There is nothing to fix in guile-git, the fix needs to go into (guix

git). The libgit2 (which guile-git is wrapping) simply does not

guarantee that two gets of the same commit hash will return identical

pointer. So I believe (guix git) is in the wrong here for using eq?.

Well, I guess guile-git could go beyond what libgit2 promises, and

introduce its own caching layer, but I am not sure that is the correct

course of action. But its up to Ludo' of course.

Tomas

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

Leo Famulari wrote on 9 Mar 20:27 -0700

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)

Message-ID:Z85cEKiiRJ9mecXr@jasmine.lan

On Mon, Mar 10, 2025 at 12:38:20AM +0100, Tomas Volf wrote:

Toggle quote (3 lines)

> There is nothing to fix in guile-git, the fix needs to go into (guix

> git).

Sorry, my mistake.

Ludovic Courtès wrote on 10 Mar 07:24 -0700

control message for bug #76660

Recipients:(address . control@debbugs.gnu.org)

Message-ID:874j01q7zj.fsf@gnu.org

retitle 76660 Downgrade prevention triggers erroneously with 'guix pull'

quit

Ludovic Courtès wrote on 10 Mar 07:24 -0700

Recipients:(address . control@debbugs.gnu.org)

Message-ID:8734flq7zc.fsf@gnu.org

severity 76660 important

quit

Ludovic Courtès wrote on 10 Mar 07:27 -0700

Re: bug#76660: current guix pull doesn't authenticate

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)

Message-ID:87wmcxot8z.fsf@gnu.org

Tomas Volf <~@wolfsden.cz> skribis:

Toggle quote (13 lines)> Leo Famulari <leo@famulari.name> writes:
>
>> On Sun, Mar 02, 2025 at 08:08:50PM +0100, Tomas Volf wrote:
>>> Possible explanation would be that there is a bug in the descendancy
>>> detection when your current Guix is on specific commits (my guesstimate
>>> would be the trigger is having large commit message, I have reported
>>> this issue before).
>>
>> Can you share these prior reports here?
>
> I expect the root cause to be the same as in 66268.  (Man, is it over an
> year already?  The time sure does fly.)

It looks like it! Terrible that such a serious bug didn’t triaged

appropriately.

I relied there, let’s see how we can fix it.

Thanks,

Ludo’.

Simon Tournier wrote on 10 Mar 12:46 -0700

Recipients:

Message-ID:87zfhshdnr.fsf@gmail.com

Hi,

On Mon, 10 Mar 2025 at 15:27, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (6 lines)

>> I expect the root cause to be the same as in 66268. (Man, is it over an

>> year already? The time sure does fly.)

> It looks like it! Terrible that such a serious bug didn’t triaged

> appropriately.

Somehow, the fix seems to rely on “git merge-base --is-ancestor” for

implementing “commit-relation”?

Since “build: Add dependency on Git” commit

f651a359691cbe4750f1fe8d14dd964f7971f91 from Sep 26 2023 we can assume

Git is available by the code that run “commit-relation”, no?

And, to my knowledge, the implementation relying on “git merge-base

--is-ancestor” does not have the problem, right?

Last cherry on the top, from [1], the implementation relying on “git

merge-base --is-ancestor” is 35x faster.

Win-win, no? Because the fix for ’eq?’ will introduce performance cost

and ’commit-relation’ will be even slower, no?

Cheers,

simon

1: comparing commit-relation using Scheme+libgit2 vs shellout plumbing Git

Simon Tournier <zimon.toutoune@gmail.com>

Tue, 12 Sep 2023 00:48:30 +0200

id:865y4gz5q9.fsf@gmail.com

https://lists.gnu.org/archive/html/guix-devel/2023-09

https://yhetil.org/guix/865y4gz5q9.fsf@gmail.com

Ludovic Courtès wrote on 10 Mar 14:57 -0700

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:87cyeomtvg.fsf@gnu.org

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

Toggle quote (3 lines)

> Last cherry on the top, from [1], the implementation relying on “git

> merge-base --is-ancestor” is 35x faster.

Uh, interesting! I would still like to avoid shelling out to Git for

common operations, but this comparison shows there’s a lot of room to

improve the performance of the current implementation.

Ludo’.

Jack Hill wrote on 10 Mar 20:19 -0700

Recipients:(name . Tomas Volf)(address . ~@wolfsden.cz)

Message-ID:alpine.DEB.2.21.2503102254550.24671@marsh.hcoop.net

On Sun, 9 Mar 2025, Tomas Volf wrote:

Toggle quote (5 lines)

> I see few options:

> 1. Revert to previous good state using `guix pull --roll-back', and try

> pulling again. Maybe it will help.

I reverted back to the oldest guix I had, 
4eaeff997907bc1b67884a6dc087756a50f175e2, and was able to pull with 
authentication up to the newest, 42773718d5d5d42137ac84826850256fd6bed606.

Many thanks!
Jack

Simon Tournier wrote on 24 Mar 05:48 -0700

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87msdalhl3.fsf@gmail.com

Hi Ludo,

On Mon, 10 Mar 2025 at 22:57, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (9 lines)

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

>> Last cherry on the top, from [1], the implementation relying on “git

>> merge-base --is-ancestor” is 35x faster.

> Uh, interesting! I would still like to avoid shelling out to Git for

> common operations, but this comparison shows there’s a lot of room to

> improve the performance of the current implementation.

You mean the current implementation of ligbit2, right? Because, from my

poor understanding, it’s part of the performance barrier.

Cheers,

simon

Tomas Volf wrote on 25 Mar 14:01 -0700

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:87ldss6d0x.fsf@wolfsden.cz

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

Toggle quote (15 lines)> Hi Ludo,
>
> On Mon, 10 Mar 2025 at 22:57, Ludovic Courtès <ludo@gnu.org> wrote:
>> Simon Tournier <zimon.toutoune@gmail.com> skribis:
>>
>>> Last cherry on the top, from [1], the implementation relying on “git
>>> merge-base --is-ancestor” is 35x faster.
>>
>> Uh, interesting!  I would still like to avoid shelling out to Git for
>> common operations, but this comparison shows there’s a lot of room to
>> improve the performance of the current implementation.
>
> You mean the current implementation of ligbit2, right?  Because, from my
> poor understanding, it’s part of the performance barrier.

There is git_graph_descendant_of function in libgit2, but it is not

exposed by the guile-git binding. Maybe we could try to use it to

implement the check instead the current approach (which does it in

Guile). I wonder how well that would perform compared to --is-ancestor.

Tomas

There are only two hard things in Computer Science:

cache invalidation, naming things and off-by-one errors.

45mg wrote on 26 Mar 04:34 -0700

Recipients:

Message-ID:875xjw9gai.fsf@gmail.com

Tomas Volf <~@wolfsden.cz> writes:

Toggle quote (5 lines)

> There is git_graph_descendant_of function in libgit2, but it is not

> exposed by the guile-git binding. Maybe we could try to use it to

> implement the check instead the current approach (which does it in

> Guile). I wonder how well that would perform compared to --is-ancestor.

I actually opened a MR to add that binding upstream. Maybe copying the

code from there might save you a little bit of work:

https://gitlab.com/guile-git/guile-git/-/merge_requests/38

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 76660@patchwise.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 76660

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date