On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > [re Cc:ing the list] > > On Wed, 12 Nov 2008, Constantine Plotnikov wrote: > >> On Wed, Nov 12, 2008 at 5:22 PM, Johannes Schindelin >> <Johannes.Schindelin@xxxxxx> wrote: >> > >> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote: >> > >> >> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the >> >> git completes successfully but commit messages and author information >> >> are not shown. I suggest that git should fail with fatal error if such >> >> zero producing encoding is used. >> >> >> >> If the incorrect encoding name is used, the git log does not perform any >> >> re-encoding, but just display commits in their native encoding. I >> >> suggest that git should fail with fatal error in this case as well. >> > >> > Have you set the correct encoding with i18n.commitEncoding? If not, you >> > should not be surprised: Git's default encoding is UTF-8, and that fact is >> > well documented, AFAICT. >> > >> 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. A separate problem is that it allows creating commits with invalid encoding names, which may be unnoticed for a long time in an environment with uniform commitencoding settings. 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
