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

From: Patrick Steinhardt <ps@pks.im>
Date: Aug 21, 2025, 10:09 UTC
Message-ID: <aKbwabLZiWasYoBC@pks.im>
In-Reply-To: <20250821072706.GA2390046@coredump.intra.peff.net>

On Thu, Aug 21, 2025 at 03:27:06AM -0400, Jeff King wrote:

Show 32 quoted lines

> On Thu, Aug 21, 2025 at 09:15:47AM +0200, Patrick Steinhardt wrote:
> 
> > > > This error _does not_ happen in the Apple-supplied version of git:
> > > > `git version 2.39.5 (Apple Git-154)`, but does in 2.51.0, which I
> > > > installed with homebrew. (If this is a packaging error, I'll happily
> > > > report to homebrew.)
> > > 
> > > That is definitely weird, and not something I'd expect if it's just a
> > > case collision. Is it possible for you to build Git from source? If so,
> > > and the problem happens with your build of 2.51.0 but not v2.39.5, it
> > > would be very enlightening to see the results of "git bisect". We can
> > > provide more guidance if you need with that process.
> > 
> > Curious indeed. Another relevant part could be the new batched mode that
> > we have recently introduced in git-fetch(1). Previously we would've
> > updated refs one by one, and potentially that led to us writing the same
> > ref multiple times due to case-insensitivity? The result would be quite
> > broken in that case, but at least the fetch would've finished. Does make
> > me wonder though what subsequent fetches did, and whether we always tend
> > to flip-flop the value of such a ref.
> 
> Ah, good catch. That would explain the behavior change perfectly. My money is
> on a case collision, then. :)
> 
> > But with batched transactions that's not possible anymore, as we would
> > indeed try to lock the same ref twice. Assuming that this really is the
> > case, I wonder whether we should detect this case, tell the user that
> > it's impossible to store all refs on their system, and then continue
> > regardless while ejecting that specific ref from the transaction.
> 
> Maybe it is too optimistic to think that they will just start using
> reftable in Git 3.0, and we can avoid extra code to detect this?

Probably, yeah. I also think it shouldn't be too involved to have the logic in Git. We can mark transactions as allowing for failures now, so in the best case we'd just do that and then check whether we have any errors.

We could also think about generating a hint that tells the user exactly what's going on. E.g. something like this:

    You're on a case-insensitive filesystem, and the remote you are
    trying to fetch from has references that only differ in casing. It
    is impossible to store such references with the "files" backend. You
    can either accept this as-is, in which case you won't be able to
    store all remote references on disk. Or you can alternatively
    migrate your repository to use the "reftable" backend with the
    following command:

        git refs migrate --ref-format=reftable

    Please keep in mind that not all implementations of Git support this
    new format yet. So if you use tools other than Git to access this
    repository it may not be an option to migrate to reftables.

The last part is what I'm working on right now. libgit2 is fully functional now, but what is still lacking is reviews.

Patrick