Subject: bug#66268: Guix makes invalid assumptions regarding guile-git guarantees leading to guix pull failing

From: Ludovic Courtès <[email-masked]>
Date: Mon, 10 Mar 2025 22:52:05 +0100

Tomas Volf <[email-masked]> skribis:

> IIRC from all the back then, the 4kB is a (default) limit for commit
> being cache-able.  It technically is on all of commit data, not just the
> commit message, but the message is the easiest to influence.

OK.

> I did not know guile-git was supposed to guarantee it.  I assumed it is
> just a binding to libgit2, so I have expected it to have the same
> semantics.

Well, ‘eq?’ only makes sense for the Scheme objects that wrap the
underlying C objects.

> I think I would just fix this in Guix, and drop the promise on
> guile-git's side.  I am obviously unsure whether people rely on it or
> not, but given it does not work I am tempted to guess.

(guix git) relies on it and I probably wrote pieces of code with that
assumption in mind.

> I also took a quick look, and I did not find this promise actually
> being documented anywhere.

It’s documented in a test.  :-)

> However I do see the appeal in being able to use eq?.  The correct
> action probably depends on in what direction you want to take guile-git.
> Should it stay just a bindings wrapper, or should it provide extra
> features and guarantees?

It’s not really an extra feature, it’s really a core part of defining
bindings in my view; ‘define-wrapped-pointer-type’ in Guile implements
those semantics.

> But then again, I do not have much experience with weak tables, and
> guile-git internals, so maybe I overestimate the complexity.  I would be
> scared I miss some paths that return commits though.

I’m happy to provide guidance if you want to give it a try, lemme know!

Ludo’.