On Wed, Aug 20, 2025 at 05:33:23PM -0400, Jeff King wrote: > If so, and assuming you're on a case-insensitive filesystem, then the > lock files would collide. You wouldn't see anything after the fact > because git-fetch itself would create the colliding lockfile, and then > clean it up after hitting the fatal error. > > If that is the case, you can try using the reftables backend in v2.51.0. > It doesn't use the filesystem for its ref storage or locking. Something > like: > > git init --bare --ref-format=reftable The response below came to me off-list. Here it is quoted with my reply: On Sun, Aug 24, 2025 at 05:03:20PM +0100, Dave Evans wrote: > I'm sorry but I do not have an email client I could use to post to the > git mailing list. > Please could you post my thoughts on this to the list. > > https://lore.kernel.org/git/20250820213323.GA1667633@xxxxxxxxxxxxxxxxxxxxxxx/ > > I use git 2.51.0 built using Macports on a very old version of macOS > > There are a couple of repos on github that were showing this problem: > vectorgraphics/asymptote > ghc/ghc > > Both of them were bare clones. > > I applied --ref-format=reftable to the vectorgraphics/asymptote repo > and a fetch > went through to the end successfully > > The only snag I can see is that cgit no longer works. It says : > Failed to open github/vectorgraphics/asymptote: No such file or directory > > The version of cgit is about 5 years old I think that's all expected. Unlike most systems which call Git commands like for-each-ref, etc, to access the ref store, cgit is linked directly against Git's C code (something we don't support, but the cgit authors accepted as a risk). So an old version of cgit will link against an old version of Git, and won't know about reftable at all. It _might_ not even be able to detect the directory as a git repo, though I thought the reftable format was designed to let even old versions of Git see the repo (e.g., the dummy value in HEAD). -Peff
