Re: gitweb: charset problem

Daniel Barkalow [off-list ref] writes:

On Mon, 24 Oct 2005, Horst von Brand wrote:

quoted

I believe the Emperor Penguin decreed messages have to be
ASCII, or else UTF-8. Please don't add to the mess by using
non-portable encodings!

Should we possibly reject non-UTF-8 input to commits?

Please, don't.

IIRC, we actually define that to be UTF-8, unlike most of the
other stuff, for which we don't actually insist on a policy.

No, we do not define nor insist on a particluar policy as far as
I know.  We suggest the use of UTF-8 merely from common sense to
help interoperability, and make UTF-8 slightly easier to use
than other encodings by giving specific support for it in some
tools, namely -u flag in git-mailinfo.

It is perfectly reasonable if a company internal project that
works in Russia to standardize on KOI, or in Japan on EUC-JP.
We simply allow it without encouraging nor discouraging it.  If
gitweb can take a configuration mechanism to override the
built-in UTF-8 header, that is perfectly a valid thing to do to
help such an environment.

However, we suggest UTF-8 if the project does not have a
compelling reason to do otherwise [*1*].  If you want to be
prepared for the day your project might have wider participants
than you originally envisioned, that is the most sensible thing
to do.  This is especially true because the commit logs cannot
be re-encoded after the fact.

[Footnote]

*1* For example, I've never made GNU emacs to work well with
Japanese in UTF-8 , so if people in my company internal project
wanted to use Japanese in commit logs, I would probably
standardize on EUC-JP for such a project.  Luckily so far I have
not been forced to make that decision.