Re: Git, Mac OS X and German special characters

From: Jay Soffian <jaysoffian@gmail.com>
Date: May 20, 2010, 15:50 UTC
Message-ID: <AANLkTil2N2xP1CWj0xxskOn-KCN1JMpJS8d3WpT5Mdg2@mail.gmail.com>
In-Reply-To: <4BF4FA89.2040904@gmail.com>

2010/5/20 Torsten Bögershausen <totte.enea@gmail.com>:

Show 7 quoted lines

> Improved interwork between Mac OS X and linux when umlauts are used
> When a git repository containing utf-8 coded umlaut characters
> is cloned onto an Mac OS X machine, the Mac OS system will convert
> all filenames returned by readdir() into denormalized utf-8.
> As a result of this conversion, git will not find them on disk.
> This helps by treating the NFD and NFD version of filenames as
> identical on Mac OS.

So this is an edge case, but what happens if a repo has both the NFC and NFD representation of a given name? It should be handled the same way as if a repo has both "File" and "file" and you try to check-out onto a case-insensitive filesystem.

Additionally, note this paragraph from 1102952 (Make git-add behave more sensibly in a case-insensitive environment, 2008-03-22):

    However, if we actually have *both* a file called "File" and one called
    "file", and they don't have the same lstat() information (ie we're on a
    case-sensitive filesystem but have the "core.ignorecase" flag set), we
    will error out if we try to add them both.

To be consistent, shouldn't we have a core.HFSPlusCompat that can be set on non-braindamaged filesystems to prevent filenames which would alias on HFS+ from entering the repo?

   http://developer.apple.com/mac/library/technotes/tn/tn1150.html#UnicodeSubtleties

j.