Re: [PATCH v3 0/4] refs/files: fix issues with git-fetch on case-insensitive FS

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 17, 2025, 17:04 UTC
Message-ID: <xmqqjz1xc8nm.fsf@gitster.g>
In-Reply-To: <CAOLa=ZSBpSyU0V08OBrr-QPrZPsYnO1bTZewESY=C7Jy4NTcWQ@mail.gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

Show 10 quoted lines

>> I've noticed another issue though, at the moment it's possible to create
>> a ref like `refs/heads/foo.Lock`. I can image this gives issue when the
>> remote has `refs/heads/foo` and `refs/heads/foo.Lock` and you pull those
>> in on a case-insensitive FS. Unfortunately I wasn't able to verify this.
>> But anyhow, I don't think that any reason to hold back on this current
>> patch series. I approve.
>
> We don't fetch locks from remote. The locking mechanism is simply a
> construct used to update files locally in race-free manner. Locking a
> file ensures no other concurrent writes can happen.

I am not Toon, but I think Toon meant "foo.Lock" to be a funnily named but a valid branch the remote has.

Doesn't the remote advertise refs/heads/foo and refs/heads/foo.Lock in such a case? And we can ask for both of them. When updating foo, we would locally create "refs/heads/foo.lock" and then rename it to refs/heads/foo", right? I think Toon's point was what happens when the fetch of "foo.Lock" from there somehow has completed first. Or we can simply fetch foo.Lock branch and then foo branch in a separate invocation of "git fetch"---now wouldn't the second invocation have trouble creating the lock file foo.lock for foo on certain filesystems?

> In-short when you fetch references, the prepare stage of the reference
> transaction will create the necessary lock files. This locks in the
> updates with guarantee that no other process can update/create the refs.
> The commit phase simply removes the lock files post updating the refs.