Re: "lock file exists" when fetching in bare clone of repository

[Patrick Steinhardt <ps@pks.im>]

On Tue, Aug 26, 2025 at 07:19:52AM -0400, Jeff King wrote:
> On Wed, Aug 20, 2025 at 05:33:23PM -0400, Jeff King 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@coredump.intra.peff.net/
> >
> > 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).

Yeah, in theory old versions of Git should still be able to discover the
Git repository. They should bail out due to the "refstorage" extension,
but other than that all files that need to exist for Git to discover the
repository still exist with the reftable backend.

If that's not the case this is a bug we'd have to fix.

Patrick