{"thread":{"id":"16236","subject":"[PATCH (GITK)] gitk: Fix commit encoding support.","startedAt":"2008-11-09T15:06:07Z","lastAt":"2008-11-13T11:42:58Z","messageCount":4,"participants":["Alexander Gavrilov","Paul Mackerras"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"95261","messageId":"200811091806.07550.angavrilov@gmail.com","threadId":"16236","inReplyTo":null,"subject":"[PATCH (GITK)] gitk: Fix commit encoding support.","fromName":"Alexander Gavrilov","fromEmail":"angavrilov@gmail.com","sentAt":"2008-11-09T15:06:07Z","receivedAt":"2008-11-09T15:06:07Z","isPatch":true,"sender":{"key":"angavrilov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42666?v=4"},"body":"This commit fixes two problems with commit encodings:\n\n1) git-log actually uses i18n.logoutputencoding to generate\n   its output, and falls back to i18n.commitencoding only\n   when that option is not set. Thus, gitk should use its\n   value to read the results, if available.\n\n2) The readcommit function did not process encodings at all.\n   This led to randomly appearing misconverted commits if\n   the commit encoding differed from the current locale.\n\nNow commit messages should be displayed correctly, except\nwhen logoutputencoding is set to an encoding that cannot\nrepresent charecters in the message. For example, it is\nimpossible to convert Japanese characters from Shift-JIS\nto CP-1251 (although the reverse conversion works).\n\nSigned-off-by: Alexander Gavrilov <angavrilov@gmail.com>\n---\n gitk |   25 +++++++++++++++++++++++--\n 1 files changed, 23 insertions(+), 2 deletions(-)\n\ndiff --git a/gitk b/gitk\nindex ae775b1..3834fc0 100755\n--- a/gitk\n+++ b/gitk\n@@ -1555,9 +1555,27 @@ proc chewcommits {} {\n     return 0\n }\n \n+proc do_readcommit {id} {\n+    global tclencoding\n+\n+    # Invoke git-log to handle automatic encoding conversion\n+    set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]\n+    # Read the results using i18n.logoutputencoding\n+    fconfigure $fd -translation lf -eofchar {}\n+    if {$tclencoding != {}} {\n+\tfconfigure $fd -encoding $tclencoding\n+    }\n+    set contents [read $fd]\n+    close $fd\n+    # Remove the heading line\n+    regsub {^commit [0-9a-f]+\\n} $contents {} contents\n+\n+    return $contents\n+}\n+\n proc readcommit {id} {\n-    if {[catch {set contents [exec git cat-file commit $id]}]} return\n-    parsecommit $id $contents 0\n+    if {[catch {set contents [do_readcommit $id]}]} return\n+    parsecommit $id $contents 1\n }\n \n proc parsecommit {id contents listed} {\n@@ -10565,6 +10583,9 @@ set gitencoding {}\n catch {\n     set gitencoding [exec git config --get i18n.commitencoding]\n }\n+catch {\n+    set gitencoding [exec git config --get i18n.logoutputencoding]\n+}\n if {$gitencoding == \"\"} {\n     set gitencoding \"utf-8\"\n }\n-- \n1.6.0.3.15.gb8d36\n"},{"id":"95330","messageId":"18712.7942.767651.569321@cargo.ozlabs.ibm.com","threadId":"16236","inReplyTo":"200811091806.07550.angavrilov@gmail.com","subject":"Re: [PATCH (GITK)] gitk: Fix commit encoding support.","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2008-11-10T11:46:14Z","receivedAt":"2008-11-10T11:46:14Z","isPatch":true,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Alexander Gavrilov writes:\n\n> +proc do_readcommit {id} {\n> +    global tclencoding\n> +\n> +    # Invoke git-log to handle automatic encoding conversion\n> +    set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]\n> +    # Read the results using i18n.logoutputencoding\n> +    fconfigure $fd -translation lf -eofchar {}\n> +    if {$tclencoding != {}} {\n> +\tfconfigure $fd -encoding $tclencoding\n\nDoes this mean there are two conversions going on, one inside git log\nand another inside Tcl?  Is there a reason why it's better to do two\nconversions than one, or is it just more convenient that way?\n\nWould an alternative approach have been to read the output of git\ncat-file with -translation binary, look for an encoding header, and do\nan encoding convertfrom based on the encoding header?  What would be\nthe disadvantage of such an approach?\n\nPaul.\n"},{"id":"95333","messageId":"bb6f213e0811100406l2fcde5b8k8772360947b948fd@mail.gmail.com","threadId":"16236","inReplyTo":"18712.7942.767651.569321@cargo.ozlabs.ibm.com","subject":"Re: [PATCH (GITK)] gitk: Fix commit encoding support.","fromName":"Alexander Gavrilov","fromEmail":"angavrilov@gmail.com","sentAt":"2008-11-10T12:06:39Z","receivedAt":"2008-11-10T12:06:39Z","isPatch":true,"sender":{"key":"angavrilov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42666?v=4"},"body":"On Mon, Nov 10, 2008 at 2:46 PM, Paul Mackerras <paulus@samba.org> wrote:\n> Alexander Gavrilov writes:\n>\n>> +proc do_readcommit {id} {\n>> +    global tclencoding\n>> +\n>> +    # Invoke git-log to handle automatic encoding conversion\n>> +    set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]\n>> +    # Read the results using i18n.logoutputencoding\n>> +    fconfigure $fd -translation lf -eofchar {}\n>> +    if {$tclencoding != {}} {\n>> +     fconfigure $fd -encoding $tclencoding\n>\n> Does this mean there are two conversions going on, one inside git log\n> and another inside Tcl?  Is there a reason why it's better to do two\n> conversions than one, or is it just more convenient that way?\n\nThat makes the processing flow uniform with the usual code path.\n\n> Would an alternative approach have been to read the output of git\n> cat-file with -translation binary, look for an encoding header, and do\n> an encoding convertfrom based on the encoding header?  What would be\n> the disadvantage of such an approach?\n\nIf all commits were loaded through cat-file, that would be the way to\ngo. Otherwise, when one code path uses one method of conversion, and\nanother one, which is used rarely and semi-randomly, a different\nmethod, it may lead to confusing results if something goes slightly\nwrong.\n\nAlexander\n"},{"id":"95677","messageId":"18716.4802.663635.847263@cargo.ozlabs.ibm.com","threadId":"16236","inReplyTo":"bb6f213e0811100406l2fcde5b8k8772360947b948fd@mail.gmail.com","subject":"Re: [PATCH (GITK)] gitk: Fix commit encoding support.","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2008-11-13T11:42:58Z","receivedAt":"2008-11-13T11:42:58Z","isPatch":true,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Alexander Gavrilov writes:\n\n> If all commits were loaded through cat-file, that would be the way to\n> go. Otherwise, when one code path uses one method of conversion, and\n> another one, which is used rarely and semi-randomly, a different\n> method, it may lead to confusing results if something goes slightly\n> wrong.\n\nOK, that makes sense.  I applied the patch with a paragraph added to\nthe description that explains that.\n\nThanks,\nPaul.\n"}]}