Re: gitweb on kernel.org and UTF-8

[Junio C Hamano <junkio@cox.net>]

Ryan Anderson <ryan@michonline.com> writes:

> On Wed, Nov 23, 2005 at 07:24:38PM -0800, Junio C Hamano wrote:
>> 
>> How about doing something like this?
>> 
>> 	[i18n]
>>         	commitEncoding = utf8
>> 		blobEncoding = utf8
>> 
>> to mean:
>> 
>> 	If you _have_ to make an assumption on an encoding
>> 	commit and blob objects are in, utf8 is your best bet
>> 	(but mistakes can happen, and some blobs can be binary).
>
> The rest of the options help clarify this, but can you make these
> options 'assumeCommitEncoding' and 'assumeBlobEncoding' to make it clear
> that these are *assumptions* and not actually controlling what gets
> written?

As I outlined in the "editorEncoding" part, if everything works
as planned, your latin-1 editing editor would leave latin-1
message for git-commit to pick up (or command line "-m $msg"
option would be encoded in latin-1), and iconv would munge that
to utf8 to feed commit-tree (because of "commitEncoding" being
utf8). In that sense, commitEncoding is not assumption for the
writers.  If everybody, including outside sources we merge from,
makes best effort not to screw up, these settings would
faithfully describe what encoding logs are in.

But writers can screw up, and funnily encoded commit messages
merge from outside source brings in cannot be fixed after the
fact, so "assume" part must be implied anyway for readers.