From: Karthik Nayak Date: Wed, 17 Sep 2025 15:24:40 GMT Subject: Re: [PATCH v3 0/4] refs/files: fix issues with git-fetch on case-insensitive FS Message-ID: In-Reply-To: <874it1noh2.fsf@iotcl.com> Toon Claes writes: > Karthik Nayak writes: > >> I did respond to Justin, I think there were a few small nits around >> grammar in the commit messages and a question around error reporting. >> >> I have applied the grammar fixes locally and don't think they warrant a >> re-roll. Regarding the error reporting. I think it is good the way it >> is. >> >> So I would say this is good as is and I will refrain for sending in >> a new version, unless there is some other concern. > > I also gave it a round of review, and I agree it's good to go. > Thanks, appreciate the review! > 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. 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. > > -- Toon