git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: GIT character codecs

From
MCMarco Costalba <mcostalba@yahoo.it>
Date
Nov 13, 2005, 08:14 UTC
Message-ID
<20051113081443.38296.qmail@web26309.mail.ukl.yahoo.com>
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
Next: Junio C Hamano
Message 1 of 4 in “Re: GIT character codecs”
  1. Marco CostalbaNov 13, 2005
  2. Junio C HamanoNov 13, 2005
  3. Matthias UrlichsNov 14, 2005
  4. Linus TorvaldsNov 13, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.