Re: [PATCH] lockfile: add case insensitive filesystem note

From: Karthik Nayak <karthik.188@gmail.com>
Date: Sep 23, 2025, 09:03 UTC
Message-ID: <CAOLa=ZQKygjjW8s3wfyCyrv1CwHzHnmMPPSU_4pNAzEuy-hx+Q@mail.gmail.com>
In-Reply-To: <aNJSnUGzzMlmrDQw@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 17 quoted lines

> On Mon, Sep 22, 2025 at 09:54:44PM +0000, Alan Da Costa via GitGitGadget wrote:
>> From: Alan Da Costa <alandacosta@gmail.com>
>> When running git fetch or git pull on a case insensitive filesystem
>> (e.g., default macOS), if multiple case variants of the same remote ref
>> exist (often after a case-only rename), both variant locks map to the
>> same on-disk path. When a local update is required, Git creates a lock
>> for the first variant and then attempts to lock the second, which
>> collides with the same lock file, so an “existing lock” error is
>> reported. The underlying issue is mixed-case refs; resolve it by
>> consolidating the remote to a single-case variant and update local refs
>> accordingly.
>
> Are you aware of Karthik's recent patch series at [1]? It looks like
> this addresses your exact problem in a more direct way, and the
> resulting error messages that we have in that patch series also give a
> bit more advice for how to handle the situation.
>

Thanks for tagging me.

>
> The patch series wasn't merged yet, but will probably be merged soon.
> Could you maybe test that series and say whether it addresses your need?
>

I agree. This should ideally be fixed with my series. Do let us know if you test it. My series also has the added advantage that it would suggest using reftables, wherein, the user can still use case-conflicting refs in their repository.

Show 5 quoted lines

> Thanks!
>
> Patrick
>
> [1]: https://lore.kernel.org/git/20250902-587-git-fetch-1-fails-fetches-on-case-insensitive-repositories-v1-0-35e69bbb507d@gmail.com/