{"thread":{"id":"23599","subject":"MIME problem when using git format-patch / git am","startedAt":"2010-04-25T23:35:49Z","lastAt":"2010-04-27T15:32:50Z","messageCount":4,"participants":["Øyvind A. Holm","Jonathan Nieder","Peter Krefting"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140372","messageId":"20100425233549.GA8737@triton","threadId":"23599","inReplyTo":null,"subject":"MIME problem when using git format-patch / git am","fromName":"Øyvind A. Holm","fromEmail":"sunny@sunbase.org","sentAt":"2010-04-25T23:35:49Z","receivedAt":"2010-04-25T23:35:49Z","isPatch":false,"sender":{"key":"sunny@sunbase.org","avatar":"https://avatars.githubusercontent.com/u/113445?v=4"},"body":"I have a problem when using `git format-patch` and `git am` when there \nare 8-bit (i.e. UTF-8) characters in the log message from line three and \nbelow. I have attached a script (`runme.sh`) for reproducing this. It is \nalso available from <http://gist.github.com/378785> in case the \nattachment is mangled.\n\nMy output is this:\n\n    $ ./runme.sh\n    LANG=en_GB.UTF-8\n    LANGUAGE=en_GB.UTF-8\n    LC_COLLATE=C\n    LC_CTYPE=en_GB.utf8\n\n    Initialized empty Git repository in /home/sunny/src/git/til_git-lista/dir/.git/\n    [master (root-commit) 2755112] Initial commit\n\n    ======== Create commits\n    [master 9ab743b] First commit without 8-bit chars\n     1 files changed, 1 insertions(+), 0 deletions(-)\n     create mode 100644 foo.txt\n    [master dd5bdf2] Second commit with © in first line of logmsg\n     1 files changed, 1 insertions(+), 0 deletions(-)\n    [master 82a445a] Third commit with no 8-bit in first line but €uro further down\n     1 files changed, 1 insertions(+), 0 deletions(-)\n    [master 42881f1] Fourth commit with © in first line again\n     1 files changed, 1 insertions(+), 0 deletions(-)\n\n    ======== git format-patch firstrev\n    0001-First-commit-without-8-bit-chars.patch\n    0002-Second-commit-with-in-first-line-of-logmsg.patch\n    0003-Third-commit-with-no-8-bit-in-first-line.patch\n    0004-Fourth-commit-with-in-first-line-again.patch\n\n    ======== Create new, empty branch and apply patches\n    Switched to a new branch 'patches'\n    Applying: First commit without 8-bit chars\n    Applying: Second commit with © in first line of logmsg\n    Applying: =?UTF-8?q?Third=20commit=20with=20no=208-bit=20in=20first=20line\n    Applying: Fourth commit with © in first line again\n\n    ======== git log\n    commit 58bcf14aee4b17152ae1f8bd40a24141e93897ec\n    Author: Øyvind A. Holm <sunny@sunbase.org>\n    Date:   0 seconds ago\n\n        Fourth commit with © in first line again\n\n    commit 56e98bd6b161510687abd658728f92b3bd85baf1\n    Author: Øyvind A. Holm <sunny@sunbase.org>\n    Date:   1 seconds ago\n\n        =?UTF-8?q?Third=20commit=20with=20no=208-bit=20in=20first=20line\n\n        =20but=20=E2=82=ACuro=20further=20down?=\n        MIME-Version: 1.0\n        Content-Type: text/plain; charset=UTF-8\n        Content-Transfer-Encoding: 8bit\n\n    commit 55de5c9008c53a388439f0a0cdb2043d9a36ba6b\n    Author: Øyvind A. Holm <sunny@sunbase.org>\n    Date:   1 seconds ago\n\n        Second commit with © in first line of logmsg\n\n    commit af6bf42a07208bc31d537a50562a5997f02e58cb\n    Author: Øyvind A. Holm <sunny@sunbase.org>\n    Date:   1 seconds ago\n\n        First commit without 8-bit chars\n\n    commit 2755112f613687510803e45868751e7b85e3cd1e\n    Author: Øyvind A. Holm <sunny@sunbase.org>\n    Date:   1 seconds ago\n\n        Initial commit\n    $\n\nIf it’s messed up (wordwrap and such), it’s also available from \n<http://gist.github.com/raw/378785/output.txt>.\n\nIn this case the log message of the third commit (56e98) is unreadable. \nThis only happens when there are characters above U+0080 in the log \nmessage, but not in the first line, as that ends up as the subject. Yes, \nI’ve also tried to remove the \"Ø\" from the author name, with similar \nresults.\n\nI’m using `git format-patch`/`git am` as an easy way to import/export \ncommits between repositories and directories, and I’m thinking that \nthese commands are probably not intended for that kind of use. Are there \nany other method or some magic command line options that makes this \npossible, or is this a bug?\n\n    +-| Øyvind A. Holm <sunny@sunbase.org> - N 60.39548° E 5.31735° |-+\n    | OpenPGP: 0xFB0CBEE894A506E5 - http://www.sunbase.org/pubkey.asc |\n    | Fingerprint: A006 05D6 E676 B319 55E2  E77E FB0C BEE8 94A5 06E5 |\n    +------------| 1f818370-50c1-11df-ae95-90e6ba3022ac |-------------+\n"},{"id":"140376","messageId":"20100426014941.GA29220@progeny.tock","threadId":"23599","inReplyTo":"20100425233549.GA8737@triton","subject":"Re: MIME problem when using git format-patch / git am","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-26T01:49:41Z","receivedAt":"2010-04-26T01:49:41Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nØyvind A. Holm wrote:\n\n| git commit -m \"Initial commit\" --allow-empty\n| git tag firstrev\n| echo First line >foo.txt\n| git add foo.txt\n| git commit -m \"First commit without 8-bit chars\"\n| echo Second line >>foo.txt\n| git commit -m \"Second commit with © in first line of logmsg\" -a\n| echo Third line >>foo.txt\n| git commit -m \"Third commit with no 8-bit in first line`echo; echo but €uro further down`\" -a\n| echo Fourth line >>foo.txt\n| git commit -m \"Fourth commit with © in first line again\" -a\n| git format-patch firstrev\n| git checkout -b patches firstrev\n| git am 0*\n| git log\n[...]\n|    Applying: =?UTF-8?q?Third=20commit=20with=20no=208-bit=20in=20first=20line\n|    Applying: Fourth commit with © in first line again\n\nOn this machine, it’s even worse:\n\n    =?UTF-8?q?Third=20commit=20with=20no=208-bit=20in=20first=20line\n    \n    =20but=20=E2=82=ACuro=20further=20down?=\n    MIME-Version: 1.0\n    Content-Type: text/plain; charset=UTF-8\n    Content-Transfer-Encoding: 8bit\n\nAn encoded-word [1] is defined to be at most 75 characters long and not\nto contain whitespace.  On the other hand, multiple encoded-words\nwithin a field are required to be separated by whitespace.\n\n[1] http://tools.ietf.org/html/rfc2047\n\nThis leads to a question: what if one wants to include a word that\nquotes to more than 75 characters?  How about more than 997 ASCII\ncharacters without whitespace?  No can do.\n\nIdeally, I would like to see git quoting single words, though I admit\nI have not seen how well various user agents cope with this.\n\nMaybe this patch would give you some joy until then.  Feel free to pick\nit up and take it somewhere more useful.\n\nThanks,\nJonathan\n\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\n\ndiff --git a/pretty.c b/pretty.c\nindex d493cad..b822e24 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -131,7 +131,7 @@ needquote:\n \t\t * many programs do not understand this and just\n \t\t * leave the underscore in place.\n \t\t */\n-\t\tif (is_rfc2047_special(ch) || ch == ' ') {\n+\t\tif (is_rfc2047_special(ch) || ch == ' ' || ch == '\\n') {\n \t\t\tstrbuf_add(sb, line + last, i - last);\n \t\t\tstrbuf_addf(sb, \"=%02X\", ch);\n \t\t\tlast = i + 1;\n"},{"id":"140397","messageId":"alpine.DEB.2.00.1004260948070.22806@ds9.cixit.se","threadId":"23599","inReplyTo":"20100426014941.GA29220@progeny.tock","subject":"Re: MIME problem when using git format-patch / git am","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-04-26T08:50:39Z","receivedAt":"2010-04-26T08:50:39Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Jonathan Nieder:\n\n> This leads to a question: what if one wants to include a word that quotes \n> to more than 75 characters?\n\nYou just split it into two encoded words. The whitespace between the \nencoded words is there for syntactic reasons only, it is not included in the \nfinal result if both parts are encoded words (look at the \"Examples\" section \nof the RFC for some examples of how it works).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"140522","messageId":"20100427153250.GA14756@progeny.tock","threadId":"23599","inReplyTo":"alpine.DEB.2.00.1004260948070.22806@ds9.cixit.se","subject":"Re: MIME problem when using git format-patch / git am","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-04-27T15:32:50Z","receivedAt":"2010-04-27T15:32:50Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Peter Krefting wrote:\n> Jonathan Nieder:\n\n>> This leads to a question: what if one wants to include a word that\n>> quotes to more than 75 characters?\n>\n> You just split it into two encoded words. The whitespace between the\n> encoded words is there for syntactic reasons only, it is not\n> included in the final result if both parts are encoded words (look\n> at the \"Examples\" section of the RFC for some examples of how it\n> works).\n\nThank you.  He explains it before then, too; I should be reading more\ncarefully.\n\nI’ve been working through a full implementation of that RFC, but it\nseems that to support breaking words, Git would need to learn where the\ncharacter boundaries are.  Which means encodings would not be just opaque\nstrings as far as git cares any more.\n\nOn the bright side, the only encoding I care about is UTF-8, and that\none’s easy.\n\nJonathan\n"}]}