On Wed, Nov 12, 2008 at 7:42 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > On Wed, 12 Nov 2008, Alexander Gavrilov wrote: >> On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin >> <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
