Re: [PATCH 2/2] refs/files: handle F/D conflicts in case-insensitive FS

> Karthik Nayak <karthik.188@gmail.com> 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.
>

>> 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".
>

>> ... 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..
>

>> Reported-by: Junio C Hamano <gitster@pobox.com>
>
> Hmph, I do not recall reporting anything, but perhaps it was a long
> time ago...
>