Re: gitweb on kernel.org and UTF-8
- From
Junio C Hamano <junkio@cox.net>
- Date
- Nov 24, 2005, 06:19 UTC
- Message-ID
- <7vsltmy3cz.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <20051124050104.GC16995@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
Show 18 quoted lines
> 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.