Hi Tomas,
Somehow nobody acted over this bug report for a long time. Terrible.
wolf <w...@wolfsden.cz> skribis:
> There is an assumption made by Guix regarding guile-git, which is not
> true. The problem is demonstrated using my fork, since that is where
> I encountered it first, but official Guix will hit the same problem
> sooner or later. I will also provide an independent repository for
> the verification.
>
> Guix made a design decision to compare commit objects using eq?, based
> on the assumption that guile-git will return the same object for the
> same commit. However that assumption is wrong and can lead to fun
> issues like:
>
> ,----
> | scheme@(guile-user)> (use-modules (git) (guix git))
> | scheme@(guile-user)> (define %repo (repository-open "/tmp/my-fork"))
> | scheme@(guile-user)> (define %hash
> "d51135e8477118dc63a7e5462355cd27e884f4fb")
> | scheme@(guile-user)> (commit-relation
> | (commit-lookup %repo (string->oid %hash))
> | (commit-lookup %repo (string->oid %hash)))
> | $5 = unrelated
> `----
Ouch.
‘tests/commit.scm’ in Guile-Git checks that behavior, but maybe it’s
just a lucky case.
Two questions/comments:
1. Come up with a similar test (for Guile-Git) where commits are *not*
‘eq?’? (It it enough to create a commit with a log that’s beyond
4 KiB?)
2. Since Guile-Git has been pretending to provide that eq?-ness
guarantee, I’m tempted to fix the problem in Guile-Git, by having a
per-repository lookup table (a weak-value hash table mapping OIDs
to commits).
How does that sound?
Thanks in advance,
Ludo’.
