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

Junio C Hamano [off-list ref] writes:

Jakub Narebski [off-list ref] writes:

quoted

..., 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.

Side note.

There is one action item for shorter term I realized we would
need.  We need to make patch-id generation use unquoted
filenames, so that no matter how differently we might
reimplement quote_c_style() later, we would get the same
patch-id from the diff between the same two trees.  Currently I
think it hashes the quoted filename that appear on ---/+++ lines
(and "rename from"/"rename to" lines as well, but usually you do
not use -M/-C when computing the patch-id, so these are not
really an issue).

I think longer term plan for git should include standardizing on
how pathname encoding and content encoding are handled at the UI
layer.

And that plan _should_ eventually include the textual diff part.
But textual diff has a machine readability requirements, so we
need to proceed very carefully.  I think the patch I sent out
earlier is probably good enough if we only care about utf-8, but
would not correctly handle other sane pathname encodings such as
extended UNIX code (let alone broken but still widely used
encodings such as MS-Kanji aka Shift_JIS).