From: Junio C Hamano Date: Wed, 17 Sep 2025 17:04:45 GMT Subject: Re: [PATCH v3 0/4] refs/files: fix issues with git-fetch on case-insensitive FS Message-ID: In-Reply-To: Karthik Nayak writes: >> 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.