Re: [PATCH] commit encoding: store it in commit header rather than mucking with NUL

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 25, 2006, 00:41 UTC
Message-ID: <Pine.LNX.4.63.0612250134040.19693@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7v3b74q1c9.fsf@assigned-by-dhcp.cox.net>

Hi,

On Sun, 24 Dec 2006, Junio C Hamano wrote:

> Thanks for paying a very close attention to what is in 'pu'.

You're welcome ;-)

>  - I did not want to break existing git implementations, but
>    hadn't audited the commit header parsers to see if they do
>    not get upset when they see unrecognized header fields in
>    commit objects.

I did not really audit it, but am quite sure that only parse_commit() really walks the buffer, and even this function just ignores what comes after committer. But if I read the code correctly, then the mandatory headers ("tree parent* author committer") have to come first, in that order.

>  - I was not sure if the "assume the whole commit->buffer is in
>    the local encoding and recode it into UTF-8" is correct.

For the purpose of showing it, there is no point in using two different encodings. I am not aware of any terminal (and do not own such a terminal anyway) which can display text with parts encoded differently from the rest.

Show 14 quoted lines

>  - Existing Porcelains such as gitk know i18n.commitencoding is
>    a hint to them by the core, and expect the core to give them
>    output in the local encoding.  With the change, the core
>    feeds UTF-8 to the caller, unless the Porcelain gets the log
>    with plumbing "cat-file".  This means they either have to
>    lose code to do their own recoding (which is probably a good
>    thing in the long run), or we would need to have a flag for
>    them to tell the core not to do the conversion.  But a new
>    flag to ask for older behaviour is always a wrong way of
>    transitioning across backward incompatibility.
> 
>    I think the output conversion from the log should be more
>    explicitly asked for it, than just a mere configuration
>    variable that cannot be overriden by gitk and friends.

Probably a new flag "--encoding" to log, which sets git_commit_encoding. And the function you introduced should probably not blindly convert to UTF-8, but to the current git_commit_encoding.

Ciao, Dscho