Re: Moving a directory into another fails

[Jakub Narebski <jnareb@gmail.com>]

Dnia poniedziałek 4. grudnia 2006 21:26, Linus Torvalds napisał:
 
>>>> On Mon, 4 Dec 2006, Jakub Narebski wrote:
>>>> 
>>>>> [...] git should acquire core.filesystemEncoding configuration variable 
>>>>> which would encode from filesystem encoding used in working directory 
>>>>> and perhaps index to UTF-8 encoding used in repository (in tree objects) 
>>>>> and perhaps index.

> You guys are ignoring the _real_ problem. 
> 
> It has nothing at all to do with dependencies on external packages. The 
> REAL problem is that if you do locale-dependent trees and other git 
> objects, git will STOP WORKING.
> 
> A filename in a tree object _has_ to be see as a pure 8-bit character 
> stream. They _have_ to be compared with "memcmp()", and they have to sort 
> the same way and mean EXACTLY the same thing for everybody.

What I propose is having filename in tree object UTF-8 encoded. I don't
know if git relies heavily that filename encoding on filesystem (in working
area) is the same as in the index, is the same as in a tree object.
 
Although I'm not sure what is the problem. You checkout non US-ASCII filename
out of git; the file can have strange characters in a name, but should
encode to the filename as is in git. The problem migh be some forbidden by
filesystem characters in a filename perhaps. 

Although Wolfgang Fischer wrote (to me and Johannes Schindelin) that HFS+
uses UTF8-NFC (Normalization-Form-Composed) when creating a file, while
readdir returns encoding used by HFS+, which is UTF8-NFD (Normalization-Form-
Decomposed). [Explitive censored]

> If a filesystem cannot represent that name AS THAT BYTE SEQUENCE then the 
> filesystem is broken. No ifs, buts, maybes about it. I'm sorry, but that's 
> how it is.

We have some configuration variables to work around broken filesystems,
like core.ignoreStat, so why not core.filesystemEncoding.

-- 
Jakub Narebski