From: Shawn O. Pearce Date: Wed, 01 Aug 2007 13:38:42 GMT Subject: Re: git-gui: diff/console part does not show UTF-8 Japanese Message-ID: <20070801133842.GG20052@spearce.org> In-Reply-To: <7vvebz602q.fsf@assigned-by-dhcp.cox.net> Junio C Hamano wrote: > Nanako Shiraishi writes: > > > I was testing git-gui (i18n branch). I can see the translated > > message in the UI buttons and menus, and also commit message part shows > > Japanese strings, but I cannot get the diff part at the bottom to show > > Japanese. Because I did set the two fonts to the same font from the > > Edit/Option menu, I do not think it is the problem with the font > > settings. > > > > Can anybody help? > > I can see the same breakage in regular git-gui without i18n. > Curious. The commit message shows Japanese but diff part is > bogus. > > And the breakage is not just Japanese. I can see this with > Kristian's name by resetting a branch to 12ace0b2 and then > attempting to amend it. Interestingly enough, gitk shows the > patch as expected. I do not quite know how it is arranged > there, though. > > Now, I freely admit I do not quite know what I am doing, but > this patch that tries to mimick the handling of commit log > message seems to help it for git-gui. > > I do think using i18n.commitencoding for payload is wrong, > though. Yea, it is wrong. The patch is logically fine as-is, there's nothing wrong with it except this part. I think the reason that gitk shows the patch as expected is because it is using i18n.commitencoding for the payload, and that's only happening as a side-effect of how it used it for the commit message itself. Call it dumb luck the thing even displays right. To really Do The Right Thing(tm) here I think we need to store an encoding for each file path so we know what we are looking at when we see the file content. E.g. a gitattributes enc attribute? For some files we might be able to guess. But I have to admit, I'm not up on my encoding guessing algorithms. ;-) For XML files we can probably guess its XML ("starts with