Re: On pathnames

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Jan 25, 2008, at 4:12 AM, Junio C Hamano wrote:
Nicolas Pitre <nico@xxxxxxx> 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.

As a HFS+ user, I would welcome this very very much.

I want my tree to be seen by the rest of the world without problems, and I don't think I should impose my filesystem view of proper naming on others.

Junio, amazing write-up, many thanks.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@xxxxxxxxxxxxxxxx
Use XMPP!


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux