Re: On pathnames

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 25, 2008, 04:12 UTC
Message-ID: <7vy7ae7dcb.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.1.00.0801241722130.22568@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 18 quoted lines

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

So I do not see any downside of doing the conversion on such a filesystem but there is this "interoperability" upside.