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

Previous thread: Re: Should "pull --rebase" try to be a little cleverer? by Nicolas Pitre on Monday, January 21, 2008 - 9:42 am. (1 message)

Next thread: git-send-email not sending? by Seth Falcon on Monday, January 21, 2008 - 11:30 am. (8 messages)
From: David Kastrup
Date: Monday, January 21, 2008 - 9:48 am

git calculates hashes over filenames and sorts them.  This is not a mere

It also is a problem when operating on a filesystem that considers "ä" a

It is not the business of a file system to juggle with filename
representations.

-- 
David Kastrup

-

From: Kevin Ballard
Date: Monday, January 21, 2008 - 9:59 am

No, it's a question of hashing algorithm. And it's one that's fairly =20
easily solved simply by picking a specific nonambiguous UTF-8 encoding =20=



You're right, that probably belongs in the VFS layer, but the behavior =20=

is the same either way. You can't leave it up to user-space libraries =20=

to enforce a filesystem encoding, because you can't rely on all =20
clients to behave properly.

-Kevin Ballard

--=20
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com


From: Dmitry Potapov
Date: Monday, January 21, 2008 - 1:43 pm

UTF-8 is a *single* encoding, and it maps every Unicode character to
a unique binary representation. So, it is completely nonambiguous.

Dmitry
-

From: Kevin Ballard
Date: Monday, January 21, 2008 - 1:53 pm

In this case, encoding refers to normalization form, as other people  
have used it in the conversation besides me.

I suggest you stop trying to find inconsequential stuff to argue  
about, especially when a tiny bit of critical thinking would reveal  
the answer.

-Kevin Ballard

-- 
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com


From: Dmitry Potapov
Date: Monday, January 21, 2008 - 4:01 pm

I thought we spoke about HFS+, and it does not use any normalization
form, because normalization should produce binary identitical strings
for equivalent strings and HFS+ conversion does not. So, it looks

All your arguments based on confusion and the fact that some other
people were probably confused does not make your arguments any more

IMHO, most of your arguments are inconsequential stuff, so I am not
sure what I am supposed to do about your writings. Probably, it does
not make sense to respond your mails anymore...

As to critical thinking, it definitely reveals that Apple's choice
was far from being. Is it so difficult to accept?

Anyway, if you think that you know better than other how to properly
deal with the problem, why don't you try to actually *do* something
and write some code that works as your propose.

Dmitry
-

From: David Kastrup
Date: Monday, January 21, 2008 - 2:05 pm

There exists more than one "normalization form" (even across MacOS
platforms), and git is cross-platform.  And people can't be made to
agree on normalization forms, anyway.  You are aware that Unicode code
points are shared between some Chinese and Japanese signs, and that
stroked forms might be composed differently in different languages?  We
don't need to go to the Far East, anyway: in Turkish, İ and i are
equivalent, as are I and ı, whereas in other European languages, I is
instead equivalent to i.  In the Netherlands, ÿ is IIRC equivalent to

Now that you have established that you are the only person on the list
capable of critical thinking, how about going elsewhere where you can
find similarly sharp critical thinkers?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-

Previous thread: Re: Should "pull --rebase" try to be a little cleverer? by Nicolas Pitre on Monday, January 21, 2008 - 9:42 am. (1 message)

Next thread: git-send-email not sending? by Seth Falcon on Monday, January 21, 2008 - 11:30 am. (8 messages)