Jakub Narebski <jnareb@xxxxxxxxx> writes: > ..., without > resolving the strange filenames problem (it would be nice if somebody was > to send code; well Junio send patch to address core git filename quoting > issue). Having showed that patch, I do not think it is a good way to go. I think the UI layer like gitweb should have freedom to choose its own pathname handling, and should read from -z output. The git plumbing is agnostic to the character encoding issues, and does not care what character set pathnames are encoded, and what character set the file contents are encoded. These are very project specific and should be handled per project. One of the primary purposes, aside from being understandable by humans, of human readable "git diff" format is to convey machine readable information without corruption in text form transport (think "e-mail"), so quoting pathnames to avoid high-bits has clear advantage (pathname character set and file contents character set are often different, and when both are non-ascii we would need to sacrifice one if we spit diff out in a single text file --- we choose to quote pathnames so that it would not interfere with file contents, which would be more important to be inspectable by humans reading "diff" output). People in the past suggested converting everything to UTF-8 but that is not a usable robust solution in the real world. The HTML output generated by gitweb do not have the "machine readably robust" requirement, so it _can_ stress more on readability by humans, including converting both pathname and contents to UTF-8; for this, the project needs to tell gitweb what its pathname character encoding is, and blob contents encoding, at the worst case blob-by-blob, but more often path-by-path. - 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