Re: git on MacOSX and files with decomposed utf-8 file names

[Dmitry Potapov <dpotapov@gmail.com>]

Hi,

[please do not top post. Just delete everything you do not reply to]

On Fri, Jan 18, 2008 at 03:24:34PM -0500, Kevin Ballard wrote:
> As far as I can tell, the only time you ever run into the problems  
> you've described on a filesystem which treats filenames as unicode  
> strings (and therefore is free to normalize), are when you're trying  
> to interact with a filesystem that treats filenames as sequences of  
> bytes.

If you read the first message in this thread, you would probably know
that the problem exists on Mac even without any other filesystem being
involved. My understanding of it is that is caused by HFS+ converting
one sequence of Unicode characters (generated by Mac keyboard driver)
to another sequence using "fast decomposed" conversion.

[And please stop calling by normalization what is not. Mac does NOT
normalize Unicode strings, it uses some sub-standard conversion,
which neither produce a normalized string nor is guaranteed to be
stable across versions of Unicode.]

> This doesn't mean treating filenames as unicode strings is wrong, it  
> just means that the world would be much better if every filesystem had  
> the same behaviour here. It's kinda like the endian issue, except  
> there's no simple solution here.

Actually, there is, if you care to do something. You can write a wrapper
around readdir(3) that will recodes filenames in Unicode Normal Forms C.
This does not require much knowledge of Git -- what it requires the
desire to do something to solve the problem. Of course, this step alone
is not a complete solution (it does not solve case-insensitive issue),
but the first step in the right direction...

BTW, Git is far from being only software that ran into this problem with
Mac. But not being first, we can benefit from other people experiences:
http://osdir.com/ml/network.gnutella.limewire.core.devel/2003-01/msg00000.html


Dmitry