Re: [PATCH/RFC (take 2)] gitweb: New improved patchset view

Jakub Narebski [off-list ref] 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.