{"thread":{"id":"29682","subject":"[PATCH 1/4] t3900: add missing UTF-16.txt and mark the test successful","startedAt":"2012-02-21T14:24:49Z","lastAt":"2012-02-23T11:25:21Z","messageCount":12,"participants":["Nguyễn Thái Ngọc Duy","Nguyen Thai Ngoc Duy","Junio C Hamano","Jeff King","Peter Krefting"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"185075","messageId":"1329834292-2511-1-git-send-email-pclouds@gmail.com","threadId":"29682","inReplyTo":null,"subject":"[PATCH 1/4] t3900: add missing UTF-16.txt and mark the test successful","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-21T14:24:49Z","receivedAt":"2012-02-21T14:24:49Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n t/t3900-i18n-commit.sh | 4 ++--\n t/t3900/UTF-16.txt | Bin 0 -> 18 bytes\n 2 files changed, 2 insertions(+), 2 deletions(-)\n create mode 100644 t/t3900/UTF-16.txt\n\ndiff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh\nindex d48a7c0..a9e5662 100755\n--- a/t/t3900-i18n-commit.sh\n+++ b/t/t3900-i18n-commit.sh\n@@ -34,9 +34,9 @@ test_expect_success 'no encoding header for base case' '\n \ttest z = \"z$E\"\n '\n \n-test_expect_failure 'UTF-16 refused because of NULs' '\n+test_expect_success 'UTF-16 refused because of NULs' '\n \techo UTF-16 >F &&\n-\tgit commit -a -F \"$TEST_DIRECTORY\"/t3900/UTF-16.txt\n+\ttest_must_fail git commit -a -F \"$TEST_DIRECTORY\"/t3900/UTF-16.txt\n '\n \n \ndiff --git a/t/t3900/UTF-16.txt b/t/t3900/UTF-16.txt\nnew file mode 100644\nindex 0000000000000000000000000000000000000000..8d0945b8e0a734ced8948da29ed9f8c65e3ec775\nGIT binary patch\nliteral 18\nVcmezW&xIi$409P$8B!Ry7yv#b1kV5f\n\nliteral 0\nHcmV?d00001\n\n-- \n1.7.8.36.g69ee2\n"},{"id":"185076","messageId":"1329834292-2511-2-git-send-email-pclouds@gmail.com","threadId":"29682","inReplyTo":"1329834292-2511-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 2/4] Do attempt pretty print in ASCII-incompatible encodings","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-21T14:24:50Z","receivedAt":"2012-02-21T14:24:50Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"We rely on ASCII everywhere. We print \"\\n\" directly without conversion\nfor example. The end result would be a mix of some encoding and ASCII\nif they are incompatible. Do not do that.\n\nIn theory we could convert everything to utf-8 as intermediate medium,\nprocess process process, then convert final output to the desired\nencoding. But that's a lot of work (unless we have a pager-like\nconverter) with little real use. Users can just pipe everything to\niconv instead.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n It seems half of the encodings \"iconv -l\" list does not pass\n ascii_superset_encoding() test. I just assume they are either exotic\n or duplicate names.\n\n pretty.c | 7 +++++++\n utf8.c | 15 +++++++++++++++\n utf8.h | 1 +\n 3 files changed, 23 insertions(+), 0 deletions(-)\n\ndiff --git a/pretty.c b/pretty.c\nindex 8688b8f..5c433a2 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -493,12 +493,19 @@ char *logmsg_reencode(const struct commit *commit,\n \t\t const char *output_encoding)\n {\n \tstatic const char *utf8 = \"UTF-8\";\n+\tstatic const char *last_output_encoding = NULL;\n \tconst char *use_encoding;\n \tchar *encoding;\n \tchar *out;\n \n \tif (!*output_encoding)\n \t\treturn NULL;\n+\tif (last_output_encoding != output_encoding) {\n+\t\tif (!ascii_superset_encoding(output_encoding))\n+\t\t\tdie(\"encoding %s is not a superset of ASCII.\",\n+\t\t\t output_encoding);\n+\t\tlast_output_encoding = output_encoding;\n+\t}\n \tencoding = get_header(commit, \"encoding\");\n \tuse_encoding = encoding ? encoding : utf8;\n \tif (!strcmp(use_encoding, output_encoding))\ndiff --git a/utf8.c b/utf8.c\nindex 8acbc66..def93ee 100644\n--- a/utf8.c\n+++ b/utf8.c\n@@ -482,3 +482,18 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e\n \treturn out;\n }\n #endif\n+\n+int ascii_superset_encoding(const char *encoding)\n+{\n+\tconst char *sample = \" !\\\"#$%&'()*+,-./0123456789:;<=>?@\"\n+\t\t\"ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\\\]^_`\"\n+\t\t\"abcdefghijklmnopqrstuvwxyz{|}~\\n\";\n+\tchar *output;\n+\tint ret;\n+\tif (!encoding)\n+\t\treturn 1;\n+\toutput = reencode_string(sample, encoding, \"US-ASCII\");\n+\tret = !output || !strcmp(sample, output);\n+\tfree(output);\n+\treturn ret;\n+}\ndiff --git a/utf8.h b/utf8.h\nindex 81f2c82..75bc128 100644\n--- a/utf8.h\n+++ b/utf8.h\n@@ -12,6 +12,7 @@ int strbuf_add_wrapped_text(struct strbuf *buf,\n \t\tconst char *text, int indent, int indent2, int width);\n int strbuf_add_wrapped_bytes(struct strbuf *buf, const char *data, int len,\n \t\t\t int indent, int indent2, int width);\n+int ascii_superset_encoding(const char *encoding);\n \n #ifndef NO_ICONV\n char *reencode_string(const char *in, const char *out_encoding, const char *in_encoding);\n-- \n1.7.8.36.g69ee2\n"},{"id":"185077","messageId":"1329834292-2511-3-git-send-email-pclouds@gmail.com","threadId":"29682","inReplyTo":"1329834292-2511-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 3/4] utf8: die if failed to re-encoding","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-21T14:24:51Z","receivedAt":"2012-02-21T14:24:51Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Return value NULL in this case means \"no conversion needed\", which is\nnot quite true when conv == -1.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n t/t4201-shortlog.sh | 2 +-\n utf8.c | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh\nindex 6872ba1..d445665 100755\n--- a/t/t4201-shortlog.sh\n+++ b/t/t4201-shortlog.sh\n@@ -27,7 +27,7 @@ test_expect_success 'setup' '\n \t\ttr 1234 \"\\360\\235\\204\\236\")\" a1 &&\n \n \t# now fsck up the utf8\n-\tgit config i18n.commitencoding non-utf-8 &&\n+\tgit config i18n.commitencoding viscii &&\n \techo 4 >a1 &&\n \tgit commit --quiet -m \"$(\n \t\techo \"This is a very, very long first line for the commit message to see if it is wrapped correctly\" |\ndiff --git a/utf8.c b/utf8.c\nindex def93ee..f918e9e 100644\n--- a/utf8.c\n+++ b/utf8.c\n@@ -444,7 +444,7 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e\n \t\treturn NULL;\n \tconv = iconv_open(out_encoding, in_encoding);\n \tif (conv == (iconv_t) -1)\n-\t\treturn NULL;\n+\t\tdie(\"failed to convert from %s to %s\", in_encoding, out_encoding);\n \tinsz = strlen(in);\n \toutsz = insz;\n \toutalloc = outsz + 1; /* for terminating NUL */\n-- \n1.7.8.36.g69ee2\n"},{"id":"185078","messageId":"1329834292-2511-4-git-send-email-pclouds@gmail.com","threadId":"29682","inReplyTo":"1329834292-2511-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 4/4] Only re-encode certain parts in commit object, not the whole","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-21T14:24:52Z","receivedAt":"2012-02-21T14:24:52Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Commit object has its own format, which happens to be in ascii, but\nnot really subject to re-encoding.\n\nThere are only four areas that may be re-encoded: author line,\ncommitter line, mergetag lines and commit body. Encoding of tags\nembedded in mergetag lines is not decided by commit encoding, so leave\nit out and consider it binary.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n pretty.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-\n 1 files changed, 57 insertions(+), 1 deletions(-)\n\ndiff --git a/pretty.c b/pretty.c\nindex 5c433a2..6ccc091 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -489,6 +489,62 @@ static char *replace_encoding_header(char *buf, const char *encoding)\n \treturn strbuf_detach(&tmp, NULL);\n }\n \n+/*\n+ * Re-encode author, committer and commit body only, leaving the rest\n+ * in ascii (or whatever the encoding it is in mergetag lines)\n+ * regardless output encoding. We assume the commit is good, so no\n+ * validation.\n+ */\n+static char *reencode_commit(const char *buffer,\n+\t\t\t const char *out_enc, const char *in_enc)\n+{\n+\tstruct strbuf out = STRBUF_INIT;\n+\tstruct strbuf buf = STRBUF_INIT;\n+\tchar *reencoded, *s, *e;\n+\n+\tstrbuf_addstr(&buf, buffer);\n+\n+\ts = strstr(buf.buf, \"\\nauthor \");\n+\tassert(s != NULL);\n+\ts += 8;\t\t\t/* \"\\nauthor \" */\n+\tstrbuf_add(&out, buf.buf, s - buf.buf);\n+\te = strchr(s, '\\n');\n+\t*e = '\\0';\n+\treencoded = reencode_string(s, out_enc, in_enc);\n+\tif (reencoded && strchr(reencoded, '\\n'))\n+\t\tdie(\"your chosen encoding produces \\\\n out of nowhere?\");\n+\tstrbuf_addstr(&out, reencoded ? reencoded : s);\n+\tfree(reencoded);\n+\n+\tstrbuf_addstr(&out, \"\\ncommitter \");\n+\tassert(!strncmp(e + 1, \"committer \", 10));\n+\ts = e + 11;\t\t/* \"\\ncommitter \" */\n+\te = strchr(s, '\\n');\n+\t*e = '\\0';\n+\treencoded = reencode_string(s, out_enc, in_enc);\n+\tif (reencoded && strchr(reencoded, '\\n'))\n+\t\tdie(\"your chosen encoding produces \\\\n out of nowhere?\");\n+\tstrbuf_addstr(&out, reencoded ? reencoded : s);\n+\tfree(reencoded);\n+\t*e = '\\n';\n+\n+\ts = e;\n+\te = strstr(s, \"\\n\\n\");\n+\tif (e) {\n+\t\te += 2;\t\t/* \"\\n\\n\" */\n+\t\tstrbuf_add(&out, s, e - s);\n+\n+\t\ts = e;\n+\t\treencoded = reencode_string(s, out_enc, in_enc);\n+\t\tstrbuf_addstr(&out, reencoded ? reencoded : s);\n+\t\tfree(reencoded);\n+\t} else\n+\t\tstrbuf_addstr(&out, s);\n+\n+\tstrbuf_release(&buf);\n+\treturn strbuf_detach(&out, NULL);\n+}\n+\n char *logmsg_reencode(const struct commit *commit,\n \t\t const char *output_encoding)\n {\n@@ -514,7 +570,7 @@ char *logmsg_reencode(const struct commit *commit,\n \t\telse\n \t\t\treturn NULL; /* nothing to do */\n \telse\n-\t\tout = reencode_string(commit->buffer,\n+\t\tout = reencode_commit(commit->buffer,\n \t\t\t\t output_encoding, use_encoding);\n \tif (out)\n \t\tout = replace_encoding_header(out, output_encoding);\n-- \n1.7.8.36.g69ee2\n"},{"id":"185081","messageId":"CACsJy8C30mTFwduiSv_z458DgDBb0O=Jn19qMSwkAHuFadtBMg@mail.gmail.com","threadId":"29682","inReplyTo":"1329834292-2511-2-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 2/4] Do attempt pretty print in ASCII-incompatible encodings","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-21T14:53:30Z","receivedAt":"2012-02-21T14:53:30Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2012/2/21 Nguyễn Thái Ngọc Duy :\n> @@ -482,3 +482,18 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e\n>        return out;\n>  }\n>  #endif\n> +\n> +int ascii_superset_encoding(const char *encoding)\n> +{\n> +       const char *sample = \" !\\\"#$%&'()*+,-./0123456789:;<=>?@\"\n> +               \"ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\\\]^_`\"\n> +               \"abcdefghijklmnopqrstuvwxyz{|}~\\n\";\n> +       char *output;\n> +       int ret;\n> +       if (!encoding)\n> +               return 1;\n> +       output = reencode_string(sample, encoding, \"US-ASCII\");\n> +       ret = !output || !strcmp(sample, output);\n> +       free(output);\n> +       return ret;\n> +}\n\nSide note about this function, which was written to ban all\nascii-incompatible charsets from entering commit objects. The idea of\nmixing charsets in the same buffer without clear boundary does not\nsound healthy. Plus, ident.c will silently drop '\\n', '<' and '>' in\nauthor/committer. If a hypothetical charset happens to place a letter\nin those, um.. code points?, the letter will be dropped. But meh..\n-- \nDuy\n"},{"id":"185089","messageId":"7vk43ggkas.fsf@alter.siamese.dyndns.org","threadId":"29682","inReplyTo":"1329834292-2511-3-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 3/4] utf8: die if failed to re-encoding","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-21T17:36:59Z","receivedAt":"2012-02-21T17:36:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Return value NULL in this case means \"no conversion needed\", which is\n> not quite true when conv == -1.\n\nDoing this only when producing new commits to avoid spreading damage might\nbe a good idea.\n\nBut utf8.c::reencode_string() is sufficiently deep in the call-chains to\nmake me suspect that the codepaths this change affects are not limited to\ncreation ones. If this also forbids readers from resurrecting salvageable\nbits while reading (imagine your commit had \"encodign vscii\" but your log\nmessage was in English, except only your name had letters outside ASCII\nthat I cannot locally convert to utf-8 for viewing), I do not think it is\nan acceptable change.\n"},{"id":"185092","messageId":"20120221182118.GA32668@sigill.intra.peff.net","threadId":"29682","inReplyTo":"1329834292-2511-2-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 2/4] Do attempt pretty print in ASCII-incompatible encodings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-21T18:21:18Z","receivedAt":"2012-02-21T18:21:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 21, 2012 at 09:24:50PM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> We rely on ASCII everywhere. We print \"\\n\" directly without conversion\n> for example. The end result would be a mix of some encoding and ASCII\n> if they are incompatible. Do not do that.\n> \n> In theory we could convert everything to utf-8 as intermediate medium,\n> process process process, then convert final output to the desired\n> encoding. But that's a lot of work (unless we have a pager-like\n> converter) with little real use. Users can just pipe everything to\n> iconv instead.\n\nI'm not sure why we bother checking this. Using non-ASCII-superset\nencodings is broken, yes, but are people actually doing that? I assume\nthat the common one is utf-16, and anybody using it will experience\nsevere breakage immediately. So are people actually doing this? Are\nthere actually encodings that will cause subtle breakage that we want to\ncatch?\n\n-Peff\n"},{"id":"185093","messageId":"20120221182559.GB32668@sigill.intra.peff.net","threadId":"29682","inReplyTo":"1329834292-2511-4-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 4/4] Only re-encode certain parts in commit object, not the whole","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-21T18:25:59Z","receivedAt":"2012-02-21T18:25:59Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 21, 2012 at 09:24:52PM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> Commit object has its own format, which happens to be in ascii, but\n> not really subject to re-encoding.\n> \n> There are only four areas that may be re-encoded: author line,\n> committer line, mergetag lines and commit body. Encoding of tags\n> embedded in mergetag lines is not decided by commit encoding, so leave\n> it out and consider it binary.\n\nIs this worth the effort? Yes, re-encoding the ASCII bits of the commit\nobject is unnecessary. But do we actually handle encodings that are not\nASCII supersets? IOW, I could see the point if this is making it\npossible to hold utf-16 names and messages in your commits (though why\nyou would want to do so is beyond me...). But my understanding is that\nthis is horribly broken anyway by other parts of the code. And even\nlooking at your code below:\n\n> +static char *reencode_commit(const char *buffer,\n> +\t\t\t const char *out_enc, const char *in_enc)\n> +{\n> +\tstruct strbuf out = STRBUF_INIT;\n> +\tstruct strbuf buf = STRBUF_INIT;\n> +\tchar *reencoded, *s, *e;\n> +\n> +\tstrbuf_addstr(&buf, buffer);\n> +\n> +\ts = strstr(buf.buf, \"\\nauthor \");\n> +\tassert(s != NULL);\n\nWouldn't this assert trigger in the presence of encodings which\ncontain ASCII NUL (e.g., wide encodings like utf-16)?\n\nIs there an encoding you have in mind which would be helped by this?\n\n-Peff\n"},{"id":"185136","messageId":"CACsJy8BZixyzf73TGPdf+_=rz59J4GWUq8B8WXuf+n97-OF=sQ@mail.gmail.com","threadId":"29682","inReplyTo":"20120221182559.GB32668@sigill.intra.peff.net","subject":"Re: [PATCH 4/4] Only re-encode certain parts in commit object, not the whole","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-22T02:01:20Z","receivedAt":"2012-02-22T02:01:20Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2012/2/22 Jeff King :\n> On Tue, Feb 21, 2012 at 09:24:52PM +0700, Nguyen Thai Ngoc Duy wrote:\n>\n>> Commit object has its own format, which happens to be in ascii, but\n>> not really subject to re-encoding.\n>>\n>> There are only four areas that may be re-encoded: author line,\n>> committer line, mergetag lines and commit body.  Encoding of tags\n>> embedded in mergetag lines is not decided by commit encoding, so leave\n>> it out and consider it binary.\n>\n> Is this worth the effort? Yes, re-encoding the ASCII bits of the commit\n> object is unnecessary. But do we actually handle encodings that are not\n> ASCII supersets? IOW, I could see the point if this is making it\n> possible to hold utf-16 names and messages in your commits (though why\n> you would want to do so is beyond me...). But my understanding is that\n> this is horribly broken anyway by other parts of the code. And even\n> looking at your code below:\n\nNo, utf-16 and friends are out of question. 617/1168 supported\nencodings in iconv translate chars 10,32-126 to something else, some\nof them does not generate NUL. I suppose none of these are actually\nused nowadays. Looking again, some don't even successfully translate\nthe given input. No, it's probably not worth the effort.\n-- \nDuy\n"},{"id":"185140","messageId":"CACsJy8AJBzZnkKSVYRuwO2T1XEWp+N1HEfiir0oWPpo0vron-A@mail.gmail.com","threadId":"29682","inReplyTo":"20120221182118.GA32668@sigill.intra.peff.net","subject":"Re: [PATCH 2/4] Do attempt pretty print in ASCII-incompatible encodings","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-02-22T02:17:58Z","receivedAt":"2012-02-22T02:17:58Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2012/2/22 Jeff King :\n> On Tue, Feb 21, 2012 at 09:24:50PM +0700, Nguyen Thai Ngoc Duy wrote:\n>\n>> We rely on ASCII everywhere. We print \"\\n\" directly without conversion\n>> for example. The end result would be a mix of some encoding and ASCII\n>> if they are incompatible. Do not do that.\n>>\n>> In theory we could convert everything to utf-8 as intermediate medium,\n>> process process process, then convert final output to the desired\n>> encoding. But that's a lot of work (unless we have a pager-like\n>> converter) with little real use. Users can just pipe everything to\n>> iconv instead.\n>\n> I'm not sure why we bother checking this. Using non-ASCII-superset\n> encodings is broken, yes, but are people actually doing that? I assume\n> that the common one is utf-16, and anybody using it will experience\n> severe breakage immediately. So are people actually doing this? Are\n> there actually encodings that will cause subtle breakage that we want to\n> catch?\n\nI did :-) once actually. But that's a good point, using unsuitable\nencoding leads to garbage output, but no subtle breakage there. It'd\nbe nice to say \"your encoding is not supported\" than throw garbage,\nbut again probably no one did it but me, and I don't feel like doing\nit again.\n-- \nDuy\n"},{"id":"185145","messageId":"7v39a3eez7.fsf@alter.siamese.dyndns.org","threadId":"29682","inReplyTo":"CACsJy8BZixyzf73TGPdf+_=rz59J4GWUq8B8WXuf+n97-OF=sQ@mail.gmail.com","subject":"Re: [PATCH 4/4] Only re-encode certain parts in commit object, not the whole","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-22T03:14:52Z","receivedAt":"2012-02-22T03:14:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"By the way, zj/term-columns topic has already graduated to 'master', so if\nyou are still interested in your earlier nd/columns topic, it would be a\ngood time to re-roll it.\n\nNo hurries, but pointing it out just in case you forgot.\n"},{"id":"185264","messageId":"alpine.DEB.2.00.1202231219050.21935@ds9.cixit.se","threadId":"29682","inReplyTo":"20120221182118.GA32668@sigill.intra.peff.net","subject":"Re: [PATCH 2/4] Do attempt pretty print in ASCII-incompatible encodings","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2012-02-23T11:25:21Z","receivedAt":"2012-02-23T11:25:21Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Jeff King:\n\n> I'm not sure why we bother checking this. Using non-ASCII-superset\n> encodings is broken, yes, but are people actually doing that?\n[...]\n> Are there actually encodings that will cause subtle breakage that we want \n> to catch?\n\nShift-JIS could be a problem; if implemented to the letter it would convert \n0x5C to a Yen character and 0x7E as an overline. Otherwise I expect it only \nbeing a problem with ISO 646 encodings, especially the ones that replace \"@\" \nwith something else [1].\n\nAlso any ISO 2022 seven-bit encoding (ISO-2022-{CN,JP,KR}) could cause \nproblems, especially if there is any preprocessing done on the string that \ndoes not respect its state-shifting (most 0x21--0x7E characters can be lead \nand trail bytes in their multi-byte modes).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n\n [1] Trying to send Internet e-mail from a system using the extended\n Swedish seven-bit encoding, where 0x40 mapped to \"É\", could\n sometimes be a challenge.\n"}]}