threads / discuss / 2484

Re: GIT character codecs

Subject: Re: GIT character codecs

## tl;dr

4 messages between Nov 13, 2005 and Nov 14, 2005.

replies: 3people: 4as markdown or json

Marco Costalba· Nov 13, 2005, 08:14 UTC · lore
Junio C Hamano wrote:
Show 9 quoted lines
>Marco Costalba <mcostalba@yahoo.it> writes:
>
>>I modified qgit to force the use of utf-8 codec instead of the local one, 
>>in my case ISO-8859-15.
>
>
>I suspect that trying to have a globa single encoding is a wrong
>approach overall.  There are a handful issues to think about.
>
I agree.
Show 31 quoted lines
>First the easiest one -- the commit log messages.  We encourage
>use of UTF-8, 
>
> [cut]
>
>But we do not _enforce_ UTF-8.
>
>What this means for qgit is that it is often sufficient for its
>log browser to support one encoding at a time, provided if it
>allows the user to switch which encoding to use depending on
>what project is being viewed.
>
>
> [cut]
>
>
>But other projects may use different
>encodings, and even a single project can have its i18n message
>files in different encodings and charsets in different files.
>Users probably want to be able to view all of them, even if they
>only understand a couple of languages and not others.
>
>What this means for qgit is that at least you should be able to
>show a whole file in a single encoding, but if you show more
>than two files at the same time, one in each window, these
>windows may be showing its contents in different encodings and
>charsets.  So you would need to give a way to your users to tell
>you what encoding each file is in.  Using global locale as the
>default and having a way to override that per file basis would
>be sufficient.
>

If encoding is a per-blob _and_ per-log message property a real solution, although cumbersone, could be that git stores encoding togheter with the blob and the commits.

The interfaces to read out encoded info could be something like 

git-rev-list --pretty --encoding git-ls-files -e

for commits and blobs respectively.

This avoids all user settings. More, the user could do not know the encoding, as example when browsing a public repo.

But I understand is too late for something like this. So what qgit can do is to show a setting with a list of all supported encodings from the user to choose from.

But this is also a problem because, first we should have _two_ settings, one from log messages and one from blobs _and_ also in this case we miss the problem of different blobs with different encoding.

A practical workaround, *that do not catches all cases at all* could be qgit has only one global setting (defaulting to local codec) and applies that setting blindly to everything, from commits to blobs, the user changes that setting and refreshes the view until he finds the correct one.

But I'm a bit reclutant to add this 'codec list' stuff because, as said, is *not* the real solution.

   Marco
		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs
Junio C Hamano· Nov 13, 2005, 10:21 UTC · re: Marco Costalba · lore
Marco Costalba <mcostalba@yahoo.it> writes:
> But I'm a bit reclutant to add this 'codec list' stuff
> because, as said, is *not* the real solution.

Why isn't it real? UNIX files do not declare what encoding they are in, and people get their work done with existing viewing or editing tools (e.g. vi, less, emacs, firefox [*1*], ...). How is your situation any different?

I suspect you could just take the default from LANG and LC_CTYPE to cover 98% of the cases, and to cover the rest 2% the problematic cases have a per-window override menu. If you first implement only the locale support without per-window override and tell your users to set these environment variables to iso-8859-15 when running qgit on your Italian project repository (or use utf-8 on git.git), wouldn't that be sufficient for most everyday uses?

[Footnotes]

*1* Ok, firefox is a bit different because they can read charset attribute from content type, but even so they have a manual override from View->CharEncoding menu to let their users cope with broken pages.

Matthias Urlichs· Nov 14, 2005, 04:47 UTC · re: Junio C Hamano · lore
Hi, Junio C Hamano wrote:
> I suspect you could just take the default from LANG and LC_CTYPE
> to cover 98% of the cases, and to cover the rest 2% the
> problematic cases have a per-window override menu.

Or, if you want to be super-flexible, just try to decode as UTF-8. Success? fine -- otherwise use whatever your application's default is set to, or your local encoding (which may of course also be UTF-8), or fall back to 8859-15.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Difficult:
	Disciplines like physics, math, engineering, which is why I don't
	want to do them.
		-- Fashionable Dictionary (www.butterfliesandwheels.com)
Linus Torvalds· Nov 13, 2005, 17:51 UTC · re: Marco Costalba · lore
On Sun, 13 Nov 2005, Marco Costalba wrote:
> 
> If encoding is a per-blob _and_ per-log message property a real solution, although cumbersone,
> could be that git stores encoding togheter with the blob and the commits.

We'd be much better off with just saying "we encourage people to use utf-8, but if you don't, just set your locale to make things show up properly".

utf-8 is clearly the future, and if we make git internally aware of locales, that's just going to complicate things. And usually for no good reason, since users don't really care that much.

I really hate codepages. I'd much rather say:
 - git is 8-bit clean, so you can use any damn encoding you want
 - utf-8 is strongly recommended for all the same reasons it's recommended 
   for anything else.
Hmm?
		Linus

← back to recent threads