Tomas Volf <~@wolfsden.cz> 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’.