On Tue, Nov 05, 2024 at 10:54:39AM -0800, Jonathan Tan wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > Everybody else seems to pass tests, but not this one > > > > https://github.com/git/git/actions/runs/11677884048/job/32516504151#step:6:1995 > > > > I am not (yet) so familiar with the topics in flight at this point, > > but there are a few topics that deal with packing, lazy fetching, > > and commit-graph and object database being out of sync, which were > > handled by a few topics by Jonathan, so I am CC'ing this if it rings > > bell for him. > > That run refers to 95dcd58, so I fetched it and tried rerunning it on > CI. It seems to pass: > > https://github.com/jonathantanmy/git/actions/runs/11690124087 I ran: ./t5616-partial-clone.sh --run=1-22 --stress and got the same familiar, though it took a while (about 40 iterations). So I think the test is just flaky and the almalinux CI just got unlucky. As for what causes the race, I have no idea. I don't see anything obviously timing oriented, so it could be something like non-deterministic hashes. In my run this: > > ++ git -C dst rev-list --missing=error --objects main > > fatal: You are attempting to fetch 957c60b67968d2ab4144e7e2fbba99d6ad864e4e, which is in the commit graph file but not in the object database. > > This is probably due to repo corruption. > > If you are attempting to repair this repo corruption by refetching the missing object, use 'git fetch --refetch' with the missing object. > > fatal: could not fetch 3246c304205324149983025431c5211438f41931 from promisor remote > > error: last command exited with $?=128 > > not ok 22 - use fsck before and after manually fetching a missing subtree Had the same 957c60b679 for the first message, but the "could not fetch $hash from promisor remote" was 3cbc3c292cd156cbe9693f32a935a42c92351583, rather than what is shown above. So maybe relevant? I'm not planning to dig further, but maybe that gives you an avenue for reproducing. -Peff
