Stefan Pfetzing wrote:

quoted text
> 2006/7/28, Petr Baudis <pasky@suse.cz>:
>>>
>>> mv: cannot stat `"gitweb/test/M\303\244rchen"': No such file or directory
>>>
> since when is this file in the official git.git tree?

Since merging in gitweb, Sat Jun 10, 2006.
 
quoted text
> Its quite problematic when used on HFS+ because it uses UTF-16 internally IMHO.
> 
> Git always thinks there is a new file in my git.git clone.

That is the problem that git tries to be content agnostict, and it
includes being coding agnostic.

I personally think that because the same repository might be deployed
on different systems with different file name encoding (and this is not
something you have control over, contrary to commit/tag message encoding,
and encoding in files), 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.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


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