Stefan Pfetzing wrote: > 2006/7/28, Petr Baudis <pasky@xxxxxxx>: >>> >>> 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html