Re: GIT character codecs

Marco Costalba [off-list ref] 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.

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)