From: Alexander Gavrilov <angavrilov@gmail.com>
Date: Mon, 10 Nov 2008 12:06:39 GMT
Subject: Re: [PATCH (GITK)] gitk: Fix commit encoding support.
Message-ID: <bb6f213e0811100406l2fcde5b8k8772360947b948fd@mail.gmail.com>
In-Reply-To: <18712.7942.767651.569321@cargo.ozlabs.ibm.com>

On Mon, Nov 10, 2008 at 2:46 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> +proc do_readcommit {id} {
>> +    global tclencoding
>> +
>> +    # Invoke git-log to handle automatic encoding conversion
>> +    set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]
>> +    # Read the results using i18n.logoutputencoding
>> +    fconfigure $fd -translation lf -eofchar {}
>> +    if {$tclencoding != {}} {
>> +     fconfigure $fd -encoding $tclencoding
>
> Does this mean there are two conversions going on, one inside git log
> and another inside Tcl?  Is there a reason why it's better to do two
> conversions than one, or is it just more convenient that way?

That makes the processing flow uniform with the usual code path.

> Would an alternative approach have been to read the output of git
> cat-file with -translation binary, look for an encoding header, and do
> an encoding convertfrom based on the encoding header?  What would be
> the disadvantage of such an approach?

If all commits were loaded through cat-file, that would be the way to
go. Otherwise, when one code path uses one method of conversion, and
another one, which is used rarely and semi-randomly, a different
method, it may lead to confusing results if something goes slightly
wrong.

Alexander