Re: gitweb: charset problem

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 25, 2005, 16:01 UTC
Message-ID: <Pine.LNX.4.64.0510251138290.25300@iabervon.org>
In-Reply-To: <7vwtk2k08z.fsf@assigned-by-dhcp.cox.net>

On Mon, 24 Oct 2005, Junio C Hamano wrote:

Show 8 quoted lines

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

I thought we'd decided on uninterpreted byte values for blobs, filenames, and trees (and everything in the working tree), but using UTF-8 for tag and commit objects.

Consider if you started a project in EUC-JP, and then decided to switch to UTF-8 later (when your environment handled it cleanly, perhaps). You could convert all the file contents and move files to re-encoded names, but you'd then want to commit these changes and have the log before and after simultaneously intelligable.

Show 7 quoted lines

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

It wouldn't be hard to convert at some point between the editor and the commit object, and you don't re-edit the commit objects like you do tracked files. It probably wouldn't even be hard for commit-tree to convert its input based on locale. (And stuff which prints commit contents for user consumption probably ought to re-encode it if necessary, too)

	-Daniel
*This .sig left intentionally blank*