Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior

From: Alexander Gavrilov <angavrilov@gmail.com>
Date: Nov 12, 2008, 16:58 UTC
Message-ID: <bb6f213e0811120858lbcefa25v47a4fb14d8537839@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0811121740120.30769@pacific.mpi-cbg.de>

On Wed, Nov 12, 2008 at 7:42 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 18 quoted lines

> On Wed, 12 Nov 2008, Alexander Gavrilov wrote:
>> On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
>> >> Commit encoding is set correctly. The problem is that git log and git
>> >> show do not support the *output* encodings UTF-16 and UCS-4 and
>> >> silently fail in that case instead of reporting the error.
>> >
>> > That looks more like an iconv bug to me.  I assume you are using Windows?
>>
>> Iconv has no way to know that git cannot work with ASCII-incompatible
>> encodings, and UTF-16 is incompatible, because it fills the output with
>> loads of zero bytes. Git both truncates messages on these bytes, and
>> forgets inserting them in strings that it produces itself.
>
> Ah, I thought that the issue was that Git would not handle commits in that
> encoding correctly.  Instead, it appears that Git cannot work with UTF-16
> _displays_.

Actually, I think that using those encodings in commits is asking for trouble too, because the encoding conversion is, as far as I remember, applied to the entire contents of the commit object, and Git, naturally, doesn't insert any null bytes in the commit headers to please the decoder. The result is a completely trashed object on output.

Also, I think that they are generally a poor choice of an encoding for data transmission, because they are ASCII-incompatible, stdlib-incompatible, unreliable to loss and addition of single bytes, and have no way to detect encoding mismatch except by metadata or heuristics: almost any string of shorts is "valid".

Alexander