From: Karthik Nayak Date: Mon, 08 Sep 2025 09:27:13 GMT Subject: Re: [PATCH 2/2] refs/files: handle F/D conflicts in case-insensitive FS Message-ID: In-Reply-To: Junio C Hamano writes: > Karthik Nayak writes: > >> Similar to the previous commit, when using the files-backend on >> case-insensitive filesystems, there is possibility of hitting F/D >> conflicts when creating references within a single transaction, such as: >> >> - 'refs/heads/foo' >> - 'refs/heads/Foo/bar' >> >> Ideally such conflicts are caught in `refs_verify_refnames_available()` >> which is responsible for checking F/D conflicts within a given >> transaction. This utility function is shared across the reference >> backends. As such, it doesn't consider the issues of using a >> case-insensitive, which only affects the files-backend. > > Sounds like a sensible way to separate the issues and > responsibilities between higher and lower layers. > I totally agree, it shouldn't know/care about specific reference backends. >> While one solution would be to make the function aware of such issues. >> This feels like... > > The first line alone is only half a sentence. "such issues. This" > -> "such issues, this". > Totally fair. Fixed. >> ... leaking implementation details of file-backend specific >> issues into the utility function. > > Very true. > >> So opt for the more simpler option, of >> lowercasing all references sent to this function when on a >> case-insensitive filesystem and operating on the files-backend. > > So when you are trying to lock "Foo", you lock "foo", for example? > How would that let the generic code liks verify_refname_available > notice that an existing ref "Foo/bar" would crash with the name you > are trying to take, which is now downcased to be "foo"? I am not > sure if the above explanation is sufficiently clear to convince > readers why it is sufficient.. > Thanks for pointing it out and also providing a test. That indeed is a problem, but that is an issue caught much earlier, creating 'foo', when 'Foo/bar' exists, fails at the locking step, since the locking step also checks for D/F conflicts. I've added another commit around this, fixing the check that you mentioned. >> Reported-by: Junio C Hamano > > Hmph, I do not recall reporting anything, but perhaps it was a long > time ago... > [snip]