Re: On pathnames

> Nicolas Pitre <nico@cam.org> writes:
>
>> On Thu, 24 Jan 2008, Junio C Hamano wrote:
>>
>>> If it is a new file, we won't find any name that is equivalent
>>> to $A in the index, and we use the name $A obtained from
>>> readdir(3).
>>>
>>> BUT with a twist.
>>>
>>> If the filesystem is known to be inconveniently case folding, we
>>> are better off registering $B instead of $A (assuming we can
>>> convert from $A to $B).
>>
>> Why?
>>
>> If you have no other representation for the file name than $A  
>> already,
>> then I don't see why Git would have to play similar evil games and
>> corru^H^H^Hnvert $A into $B.  Just store $A in the index and tree
>> objects and be done with it.
>
> Because this "conversion" is limited to the case where the
> filesystem is known to be inconveniently case folding, I
> personally do not care about this part of the outline that
> deeply.  It would not bite _me_ or my friends either way.
>
> But I would imagine that a person who has to work on HFS+ would
> appreciate it if these two sequences behaved the same way:
>
>     $ edit Märchen ;# assume this is a new file
>     $ git add Märchen ;# we were told that IM gives $B (aka NFC)
>
> vs
>
>     $ edit Märchen ;# assume this is a new file
>     $ git add M*en ;# now readdir(3) gives $A (aka NFD)
>
> If we always convert $A (less interoperable form) to $B (more
> interoperable form) on inconveniently case folding filesystems,
> the new index entry will always be in form $B.  Without the
> conversion, the former will give form $B while the latter will
> give form $A.  It is, as you said, "similar evil game to
> corrupt", but it is not even a corruption at that point, because
> the inconveniently case folding filesystem already corrupted the
> pathname before we get our hands on it, and it won't make a
> difference for HFS+ only people anyway.
>
> However, if the resulting tree that adds a new file is prepared
> on an inconveniently case folding filesystem, the conversion
> process, by definition, would make the resulting tree more
> interoperable with other systems than without.