{"thread":{"id":"21955","subject":"am fails to apply patches for files with CRLF lineendings","startedAt":"2009-12-14T18:33:37Z","lastAt":"2010-02-13T19:07:25Z","messageCount":18,"participants":["Björn Steinbrink","Junio C Hamano","Jason King","Brandon Casey","Sverre Rabbelier","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"129892","messageId":"20091214183337.GA25462@atjola.homenet","threadId":"21955","inReplyTo":null,"subject":"am fails to apply patches for files with CRLF lineendings","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-14T18:33:37Z","receivedAt":"2009-12-14T18:33:37Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"Hi,\n\nJason King (cc'd) reported that a patch for a file with CRLF lineendings\nfails to apply, even if generated and applied in the same repo.\n\ndoener@atjola:x $ git init\n\ndoener@atjola:x (master) $ for x in $(seq 10); do echo -e \"$x\\r\" >> foo; done\ndoener@atjola:x (master) $ vim foo\ndoener@atjola:x (master) $ git add foo; git commit -m init\n[master (root-commit) b59b963] init\n 1 files changed, 10 insertions(+), 0 deletions(-)\n create mode 100644 foo\n\ndoener@atjola:x (master) $ sed -ie s/5/changed/ foo\ndoener@atjola:x (master) $ git commit -am changed\n[master fe4ee44] changed\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndoener@atjola:x (master) $ git format-patch HEAD^\n0001-changed.patch\n\ndoener@atjola:x (master) $ git checkout HEAD^\nNote: moving to 'HEAD^' which isn't a local branch\n\ndoener@atjola:x ((b59b963...)) $ git am 0001-changed.patch\nApplying: changed\nerror: patch failed: foo:2\nerror: foo: patch does not apply\nPatch failed at 0001 changed\nWhen you have resolved this problem run \"git am --resolved\".\nIf you would prefer to skip this patch, instead run \"git am --skip\".\nTo restore the original branch and stop patching run \"git am --abort\".\n\nUsing \"--whitespace=fix\" makes the patch apply, but converts the changed\nline and the context area from CRLF to LF.\n\nCommit c2ca1d7 \"Allow mailsplit ... to handle mails with CRLF line-endings\"\nseems to be responsible. Using \"git am --rebasing\" to trigger the\n--keep-cr flag to mailsplit makes things work:\n\ndoener@atjola:x ((b59b963...)) $ git am --rebasing 0001-changed.patch\nApplying: changed\n\nAnd reverting that commit also gives the expected whitespace warning\n(which is somehow squelched by the --rebasing flag it seems).\n\ndoener@atjola:x ((b59b963...)) $ git am 0001-changed.patch\nApplying: changed\n/home/doener/x/.git/rebase-apply/patch:14: trailing whitespace.\nchanged\nwarning: 1 line adds whitespace errors.\n\nBjörn\n"},{"id":"129895","messageId":"7vvdg9i9mn.fsf@alter.siamese.dyndns.org","threadId":"21955","inReplyTo":"20091214183337.GA25462@atjola.homenet","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-14T20:27:44Z","receivedAt":"2009-12-14T20:27:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Steinbrink writes:\n\n> Commit c2ca1d7 \"Allow mailsplit ... to handle mails with CRLF line-endings\"\n> seems to be responsible.\n\nYes, that commit is not only responsible but was deliberate. For a better\nbackstory, see:\n\n http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721\n\nYou'd notice that I was one of the people who didn't want to have this\nchange, so you don't need to convince _me_ that this was not a change to\nkeep everybody happy, but you'd need to try a better job than I did back\nthen to convince people who thought that \"am\" should directly work on\n\"Thunderbird saved mails\" that what they want was a bad idea X-<.\n"},{"id":"129897","messageId":"7viqc9i9b9.fsf@alter.siamese.dyndns.org","threadId":"21955","inReplyTo":"7vvdg9i9mn.fsf@alter.siamese.dyndns.org","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-14T20:34:34Z","receivedAt":"2009-12-14T20:34:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Björn Steinbrink writes:\n>\n>> Commit c2ca1d7 \"Allow mailsplit ... to handle mails with CRLF line-endings\"\n>> seems to be responsible.\n>\n> Yes, that commit is not only responsible but was deliberate. For a better\n> backstory, see:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721\n>\n> You'd notice that I was one of the people who didn't want to have this\n> change, so you don't need to convince _me_ that this was not a change to\n> keep everybody happy, but you'd need to try a better job than I did back\n> then to convince people who thought that \"am\" should directly work on\n> \"Thunderbird saved mails\" that what they want was a bad idea X-<.\n\nHaving said that, I think you can tell \"format-patch\" to emit it as mime\nattachment to work this around. It _might_ even make sense to do so\nautomatically when the payload contains CRLF but that is a separate issue.\n"},{"id":"129900","messageId":"20091214205517.GA1317@atjola.homenet","threadId":"21955","inReplyTo":"776A5AB0-E6BC-4230-800E-BE1B7A6B09BF@silentcow.com","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-14T20:55:17Z","receivedAt":"2009-12-14T20:55:17Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.14 12:38:30 -0800, Jason King wrote:\n> On Dec 14, 2009, at 12:27 PM, Junio C Hamano wrote:\n> \n> >Björn Steinbrink writes:\n> >\n> >>Commit c2ca1d7 \"Allow mailsplit ... to handle mails with CRLF\n> >>line-endings\"\n> >>seems to be responsible.\n> >\n> >Yes, that commit is not only responsible but was deliberate. For\n> >a better\n> >backstory, see:\n> >\n> > http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721\n> >\n> >You'd notice that I was one of the people who didn't want to have this\n> >change, so you don't need to convince _me_ that this was not a\n> >change to\n> >keep everybody happy, but you'd need to try a better job than I\n> >did back\n> >then to convince people who thought that \"am\" should directly work on\n> >\"Thunderbird saved mails\" that what they want was a bad idea X-<.\n> \n> I dunno Junio, the back story doesn't really seem like a convincing\n> argument for totally breaking am's handling of real CRLFs. Right\n> now, it seems to be a very bad thing that git can create a patch\n> that it can't apply. The default am should always be able to apply\n> whatever format-patch has generated.\n> \n> If it's desirable to have am translate CRLFs to LFs, then why not\n> provide this as an option to am so as not to break merging of real\n> CRLF patches? Eg.:\n> \n> git am --convert-crlf\n\nHm, currently it checks everyline. I didn't really think this through,\nbut wouldn't it makes sense to have a per-mail flag, that checks just\nthe first line, and if that has CRLF, then enable the dropping (unless\n--keep-cr is given), otherwise, keep things verbatim. That should (I\nthink) make things work with non-messed up patches regardless of the\nfiles being patch, as well as with messed up patches as long as they\ndon't try to patch files with CRLF line-endings.\n\nI can't seem to come up with a clean patch though (btw, is the comment\nfor split_one that says that buf may contain a partial line still\ntrue?), but maybe I'll find some time to try again later this week\n(don't count on it though, I'm pretty stressed...)\n\nBjörn\n"},{"id":"129902","messageId":"B86FC676-FEAE-482D-953D-701A01FD2877@silentcow.com","threadId":"21955","inReplyTo":"20091214205517.GA1317@atjola.homenet","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Jason King","fromEmail":"jk@silentcow.com","sentAt":"2009-12-14T21:16:40Z","receivedAt":"2009-12-14T21:16:40Z","isPatch":false,"sender":{"key":"jk@silentcow.com","avatar":null},"body":"On Dec 14, 2009, at 12:55 PM, Björn Steinbrink wrote:\n\n> On 2009.12.14 12:38:30 -0800, Jason King wrote:\n>> On Dec 14, 2009, at 12:27 PM, Junio C Hamano wrote:\n>>\n>>> Björn Steinbrink writes:\n>>>\n>>>> Commit c2ca1d7 \"Allow mailsplit ... to handle mails with CRLF\n>>>> line-endings\"\n>>>> seems to be responsible.\n>>>\n>>> Yes, that commit is not only responsible but was deliberate. For\n>>> a better\n>>> backstory, see:\n>>>\n>>> http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721\n>>>\n>>> You'd notice that I was one of the people who didn't want to have \n>>> this\n>>> change, so you don't need to convince _me_ that this was not a\n>>> change to\n>>> keep everybody happy, but you'd need to try a better job than I\n>>> did back\n>>> then to convince people who thought that \"am\" should directly work \n>>> on\n>>> \"Thunderbird saved mails\" that what they want was a bad idea X-<.\n>>\n>> I dunno Junio, the back story doesn't really seem like a convincing\n>> argument for totally breaking am's handling of real CRLFs. Right\n>> now, it seems to be a very bad thing that git can create a patch\n>> that it can't apply. The default am should always be able to apply\n>> whatever format-patch has generated.\n>>\n>> If it's desirable to have am translate CRLFs to LFs, then why not\n>> provide this as an option to am so as not to break merging of real\n>> CRLF patches? Eg.:\n>>\n>> git am --convert-crlf\n>\n> Hm, currently it checks everyline. I didn't really think this through,\n> but wouldn't it makes sense to have a per-mail flag, that checks just\n> the first line, and if that has CRLF, then enable the dropping (unless\n> --keep-cr is given), otherwise, keep things verbatim. That should (I\n> think) make things work with non-messed up patches regardless of the\n> files being patch, as well as with messed up patches as long as they\n> don't try to patch files with CRLF line-endings.\n\nSure, it won't affect LFers at all if you test the header lines of the \npatch file - we'll be immune from that conversion then. Works for me :)\n\nThanks again,\nJason\n"},{"id":"129914","messageId":"tCQlJn153g8Oa6Z9HKe6xOUQJdcf2PCIVthlTrLgYE-wJ5jFyXVXWw@cipher.nrlssc.navy.mil","threadId":"21955","inReplyTo":"7vvdg9i9mn.fsf@alter.siamese.dyndns.org","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2009-12-14T22:56:58Z","receivedAt":"2009-12-14T22:56:58Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"Junio C Hamano wrote:\n> Björn Steinbrink writes:\n> \n>> Commit c2ca1d7 \"Allow mailsplit ... to handle mails with CRLF line-endings\"\n>> seems to be responsible.\n> \n> Yes, that commit is not only responsible but was deliberate. For a better\n> backstory, see:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721\n> \n> You'd notice that I was one of the people who didn't want to have this\n> change, so you don't need to convince _me_ that this was not a change to\n> keep everybody happy, but you'd need to try a better job than I did back\n> then to convince people who thought that \"am\" should directly work on\n> \"Thunderbird saved mails\" that what they want was a bad idea X-<.\n\nMy understanding of the problem is that rfc2822 dictates that CRLF is the\nline ending in an email message for _every_ line, and that CR cannot\noccur without LF and vice versa. So there is no reliable way to extract\npatches from the body of an email and expect line endings to be conveyed\naccurately. Some email clients save emails with the line-endings of the\nplatform, some save in what they call \"raw\" format with rfc2822's CRLF\nline endings. So we have to _assume_ that the patch extracted from the\nemail has a particular line ending and make-it-so. For better or worse\n(better for me), commit c2ca1d7 chose LF line-endings as the line-ending\nof choice.\n\nI agree that git-am should be able to apply everything that\ngit-format-patch produces. Perhaps the diff machinery should be modified\nto treat files containing \\r as binary when generating the output for\nformat-patch. Then we'd get a binary diff in the email.\n\n-brandon\n"},{"id":"129916","messageId":"7vhbrtdtth.fsf@alter.siamese.dyndns.org","threadId":"21955","inReplyTo":"tCQlJn153g8Oa6Z9HKe6xOUQJdcf2PCIVthlTrLgYE-wJ5jFyXVXWw@cipher.nrlssc.navy.mil","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-14T23:22:50Z","receivedAt":"2009-12-14T23:22:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n> My understanding of the problem is that rfc2822 dictates that...\n\nI think the fundamental problem is that what MUA uses as the internal\nstorage format doesn't necessarily have to even be RFC-2822, which only\nspecifies what should be on-the-wire. The blamed commit took things too\nfar.\n\nIt actually is the norm to use LF as the line terminator in the body text\nin saved messages (and trailing CR as a true part of the payload), and\n\"am\" traditionally used that definition. It is meant to read from \"mbox\"\nformat to begin with.\n\nBefore the blamed commit, \"am\" took what was given literally, and it\ntreated the trailing CR as part of the payload in a text file, each of\nwhose line is LF terminated. This meant that if you sent and your MUA\ndidn't corrupt, or more importantly if you ran format-patch yourself to\nproduce a patch on content with CRLF line endings and fed it to am without\nany e-mail involved, your CRLF would have been preserved. So in that\nsense, unlike what you said in your message, the blamed commit didn't\ndecide that the line termination must be LF. It decided that the line\ntermination does not matter, which is a lot worse.\n\nAs long as the use of CR is an internal storage matter and \"Save As...\"\ndoesn't add extra CR that wasn't in the original contents, I wouldn't say\nthat such a MUA is broken. In the use case that led to the blamed commit,\nthe user is choosing to read directly from the internal storage of MUA,\nbypassing its \"Save As...\" interface meant to be used to externalize the\nmessages, and the user is responsible for dealing with the fallout, hence\nmy \"dos2unix\" suggestion in the original thread.\n\nProbably we should revert that commit, unless somebody comes up with a\nbetter solution _or_ somebody convincingly argues that there shouldn't be\nCRLF in your committed history.\n"},{"id":"129922","messageId":"20091215012514.GB1317@atjola.homenet","threadId":"21955","inReplyTo":"ee63ef30912141650ie05baf4kab8505adf160c62e@mail.gmail.com","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-12-15T01:25:14Z","receivedAt":"2009-12-15T01:25:14Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.12.14 18:50:44 -0600, Brandon Casey wrote:\n> I think it is more correct to say that the line termination in an email is\n> ambiguous. CRLF does not necessarily mean that the original had CRLF line\n> termination if RFC-2822 is followed explicitly.\n\nRight. And checking, after sending a patch containing CRs with mutt, it\nlost those CRs. Even the local copy saved directly by mutt, which didn't\nleave my box, lacks the CRs. So it seems basically impossible to send\npatches to CRLF files inline.\n\nRFC-822 still allowed bare CRs/LFs :-/\n\nSo the commit didn't break with anything mails conforming to RFC-2822,\nthose won't work for files with CR being patch. But it still breaks the\nthe raw format-patch generated patches, so even attaching them to the\nactual email as a workaround won't do.\n\nThat makes a \"use the first line to decide whether or not to strip CRs\"\napproach look like a good idea. Real mails are broken anyway, and the\nformat-patch output has LF on the first line, so mailsplit wouldn't mess\nit up... Unless git on windows produces CRLF format-patch output...\n\nBjörn\n"},{"id":"129923","messageId":"ee63ef30912141809k27bc73edp20abddd5e9c7c063@mail.gmail.com","threadId":"21955","inReplyTo":"ee63ef30912141650ie05baf4kab8505adf160c62e@mail.gmail.com","subject":"Fwd: am fails to apply patches for files with CRLF lineendings","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2009-12-15T02:09:46Z","receivedAt":"2009-12-15T02:09:46Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Forwarding to the list. The original was bounced since gmail sent a\nmultipart mime version with html. Seems we can't disable html\ncomposing in the gmail settings anymore (I thought we used to be able\nto).\n\n\n---------- Forwarded message ----------\nFrom: Brandon Casey \nDate: Mon, Dec 14, 2009 at 6:50 PM\nSubject: Re: am fails to apply patches for files with CRLF lineendings\nTo: Junio C Hamano \nCc: Brandon Casey , Björn\nSteinbrink , jk@silentcow.com,\ngit@vger.kernel.org\n\n\nOn Mon, Dec 14, 2009 at 5:22 PM, Junio C Hamano wrote:\n>\n> Brandon Casey writes:\n>\n> > My understanding of the problem is that rfc2822 dictates that...\n>\n> I think the fundamental problem is that what MUA uses as the internal\n> storage format doesn't necessarily have to even be RFC-2822, which only\n> specifies what should be on-the-wire.\n\nIf CRLF is what is on-the-wire, how can the MUA tell whether the\noriginal was also CRLF or whether it was only LF?  My assumption was\nthat the MUA cannot tell, and that things worked for most people\nbecause those people who wanted LF terminated output were on platforms\nthat used LF termination and their MUA produced output using the\nnative line termination.  Things broke recently for some people since\nthunderbird devels decided to start saving emails with CRLF\ntermination on linux.\n\n>\n>  The blamed commit took things too\n> far.\n>\n> It actually is the norm to use LF as the line terminator in the body text\n> in saved messages (and trailing CR as a true part of the payload), and\n> \"am\" traditionally used that definition.  It is meant to read from \"mbox\"\n> format to begin with.\n\nBut isn't each email in the mbox file supposed to be RFC-2822\nformatted anyway?  If so, then my reading of RFC-2822 says that there\nshould only be CRLF everywhere and no bare CR or bare LF.  But maybe\neveryone has just been ignoring that part of RFC-2822?  I'm not an\nemail expert, so I really don't know.\n\n>\n> Before the blamed commit, \"am\" took what was given literally, and it\n> treated the trailing CR as part of the payload in a text file, each of\n> whose line is LF terminated.  This meant that if you sent and your MUA\n> didn't corrupt, or more importantly if you ran format-patch yourself to\n> produce a patch on content with CRLF line endings and fed it to am without\n> any e-mail involved, your CRLF would have been preserved.  So in that\n> sense, unlike what you said in your message, the blamed commit didn't\n> decide that the line termination must be LF.  It decided that the line\n> termination does not matter, which is a lot worse.\n\nI think it is more correct to say that the line termination in an\nemail is ambiguous.  CRLF does not necessarily mean that the original\nhad CRLF line termination if RFC-2822 is followed explicitly.\n\n> As long as the use of CR is an internal storage matter and \"Save As...\"\n> doesn't add extra CR that wasn't in the original contents, I wouldn't say\n> that such a MUA is broken.  In the use case that led to the blamed commit,\n> the user is choosing to read directly from the internal storage of MUA,\n> bypassing its \"Save As...\" interface meant to be used to externalize the\n> messages,\n\nNo, we're using \"Save As...\" in thunderbird, and it saves with CRLF\nline endings.  I don't really care for thunderbird and its proclivity\nfor munging my emails and _not_ doing-the-right-thing in my opinion.\n\nMaybe someone can suggest a mail client that can use imap and provide\nthe nice sorting of emails into folders like thunderbird does.\n\n-brandon\n"},{"id":"129925","messageId":"7vfx7d7zpp.fsf@alter.siamese.dyndns.org","threadId":"21955","inReplyTo":"ee63ef30912141650ie05baf4kab8505adf160c62e@mail.gmail.com","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-12-15T02:12:02Z","receivedAt":"2009-12-15T02:12:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n>> It actually is the norm to use LF as the line terminator in the body text\n>> in saved messages (and trailing CR as a true part of the payload), and\n>> \"am\" traditionally used that definition. It is meant to read from \"mbox\"\n>> format to begin with.\n>\n> But isn't each email in the mbox file supposed to be RFC-2822 formatted\n> anyway?\n\nIf you are talking about the same \"mbox\" I was talking about, which is\nwhat I see when I peek \"/var/mail/junio\", then the answer is no. Their\nlines are terminated with a LF, and if you insert CR at the end of the\nline it would appear as true payload. DOSsy boxes can have C:\\mail\\user\nor whatever that has DOS text, of course, so there is no \"supposed to be\".\n\nHaving said that, it does not matter an iota in the real world if somebody\ndeclares on _this list_ that it a bug that Thunderbird spits out CRLF text\nin response to \"Save As...\" on platforms where LF is the natural line\nterminator [*1*]. Whether it is a bug or not, we still need to help\npeople with such a program without breaking others.\n\nI saw \"peeking the line ending of the first line\" as suggested as a\nsolution, and my gut feeling, without thinking too much about it, is\nthat it is likely to be the right thing to do, especially if we do\nboth the check and the necessary conversion in either mailinfo or even\nin mailsplit.\n\n\n[Footnote]\n\n*1* It is a different matter if it was done on _their_ mailing list, and\nit would even be better if such a discussion on _their_ mailing list\nresulted in a fix over there.\n"},{"id":"129932","messageId":"ee63ef30912141959g2da1bc65y20b9bdb93a2a8d41@mail.gmail.com","threadId":"21955","inReplyTo":"7vfx7d7zpp.fsf@alter.siamese.dyndns.org","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2009-12-15T03:59:16Z","receivedAt":"2009-12-15T03:59:16Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Mon, Dec 14, 2009 at 8:12 PM, Junio C Hamano wrote:\n> Brandon Casey writes:\n>\n>>> It actually is the norm to use LF as the line terminator in the body text\n>>> in saved messages (and trailing CR as a true part of the payload), and\n>>> \"am\" traditionally used that definition.  It is meant to read from \"mbox\"\n>>> format to begin with.\n>>\n>> But isn't each email in the mbox file supposed to be RFC-2822 formatted\n>> anyway?\n>\n> If you are talking about the same \"mbox\" I was talking about, which is\n> what I see when I peek \"/var/mail/junio\", then the answer is no.\n\nYes, that is what I was talking about, but I did not know whether the\nindividual mails which are separated by \"From user@host ...\" were\nsupposed to be in RFC-2822 format or not.\n\n> Their lines are terminated with a LF, and if you insert CR at the end of the\n> line it would appear as true payload.\n\nHow do you insert CR at the end of the line? Can you use mutt or\nsomething like it to send a mail which contains a CR? I have tried,\nand I have not been able to do so. I have tried mutt, mailx, and\nsendmail. For sendmail, I of course constructed the email headers by\nhand and piped it through sendmail. The CRLF in my tests were\nconverted to LF by the time they reached /var/mail/casey.\n\n> DOSsy boxes can have C:\\mail\\user\n> or whatever that has DOS text, of course, so there is no \"supposed to be\".\n>\n> Having said that, it does not matter an iota in the real world if somebody\n> declares on _this list_ that it a bug that Thunderbird spits out CRLF text\n> in response to \"Save As...\"  on platforms where LF is the natural line\n> terminator [*1*].\n\nI'm not sure it is a bug, just a change in behavior.\n\n> Whether it is a bug or not, we still need to help\n> people with such a program without breaking others.\n\nI agree.\n\n> I saw \"peeking the line ending of the first line\" as suggested as a\n> solution, and my gut feeling, without thinking too much about it, is\n> that it is likely to be the right thing to do, especially if we do\n> both the check and the necessary conversion in either mailinfo or even\n> in mailsplit.\n\nYes, I think it will work as a work-around, unfortunately I cannot\nwork on implementing this at the moment. I think the better solution,\nif it is not too costly, is to detect the presence of CR and produce a\nbinary patch that can be sent through email and applied by git-am.\n\n-brandon\n"},{"id":"129935","messageId":"fabb9a1e0912142233u42fc4bb6k70ef7c539cc1ae76@mail.gmail.com","threadId":"21955","inReplyTo":"ee63ef30912141809k27bc73edp20abddd5e9c7c063@mail.gmail.com","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-12-15T06:33:13Z","receivedAt":"2009-12-15T06:33:13Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Dec 15, 2009 at 03:09, Brandon Casey wrote:\n> Forwarding to the list.  The original was bounced since gmail sent a\n> multipart mime version with html.  Seems we can't disable html\n> composing in the gmail settings anymore (I thought we used to be able\n> to).\n\nYou can, it remembers when you click \"« Plain Text\", at least, it does\nfor me :P.\n\n--\nCheers,\n\nSverre Rabbelier\n"},{"id":"129948","messageId":"J6KfbWfvYNsBuf59-QHYyYOrOcWPCWp6-hwIIf7hBX8@cipher.nrlssc.navy.mil","threadId":"21955","inReplyTo":"fabb9a1e0912142233u42fc4bb6k70ef7c539cc1ae76@mail.gmail.com","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2009-12-15T16:04:45Z","receivedAt":"2009-12-15T16:04:45Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"Sverre Rabbelier wrote:\n> Heya,\n> \n> On Tue, Dec 15, 2009 at 03:09, Brandon Casey wrote:\n>> Forwarding to the list. The original was bounced since gmail sent a\n>> multipart mime version with html. Seems we can't disable html\n>> composing in the gmail settings anymore (I thought we used to be able\n>> to).\n> \n> You can, it remembers when you click \"« Plain Text\", at least, it does\n> for me :P.\n\nThanks, that seemed to be the case for the last few emails I wrote.\nThey defaulted to plain text.\n\n-brandon\n"},{"id":"129968","messageId":"m26387voiy.fsf@igel.home","threadId":"21955","inReplyTo":"20091215012514.GB1317@atjola.homenet","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2009-12-15T22:52:05Z","receivedAt":"2009-12-15T22:52:05Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Björn Steinbrink writes:\n\n> Right. And checking, after sending a patch containing CRs with mutt, it\n> lost those CRs. Even the local copy saved directly by mutt, which didn't\n> leave my box, lacks the CRs. So it seems basically impossible to send\n> patches to CRLF files inline.\n\nIf you want to send mail containing a bare CR you need to encode it.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"129969","messageId":"m2vdg7u8qk.fsf@igel.home","threadId":"21955","inReplyTo":"ee63ef30912141809k27bc73edp20abddd5e9c7c063@mail.gmail.com","subject":"Re: Fwd: am fails to apply patches for files with CRLF lineendings","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2009-12-15T23:18:27Z","receivedAt":"2009-12-15T23:18:27Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Brandon Casey writes:\n\n> But isn't each email in the mbox file supposed to be RFC-2822\n> formatted anyway?  If so, then my reading of RFC-2822 says that there\n> should only be CRLF everywhere and no bare CR or bare LF.  But maybe\n> everyone has just been ignoring that part of RFC-2822?  I'm not an\n> email expert, so I really don't know.\n\nRFC 2822 specifies a *transport* format, where each text lines is\nrepresented by terminating it with CRLF. Any other use is outside the\nscope of that RFC. The mbox format normally uses the native format for\ntext files, which means LF terminated lines when used under Unix.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"129971","messageId":"m2eimvu51f.fsf@igel.home","threadId":"21955","inReplyTo":"m26387voiy.fsf@igel.home","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2009-12-16T00:38:20Z","receivedAt":"2009-12-16T00:38:20Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Andreas Schwab writes:\n\n> Björn Steinbrink writes:\n>\n>> Right. And checking, after sending a patch containing CRs with mutt, it\n>> lost those CRs. Even the local copy saved directly by mutt, which didn't\n>> leave my box, lacks the CRs. So it seems basically impossible to send\n>> patches to CRLF files inline.\n>\n> If you want to send mail containing a bare CR you need to encode it.\n\nBtw, this mail had a stray CR added to the last line when I sent it out\n(properly encoded as quoted-printable), but that didn't make it through\ngmane. :-)\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"130847","messageId":"wtPFseZ4A1pT-STvrVsX7nC5hglK1gLCP4QZPtcSuvTN1jW0PYRUbQ@cipher.nrlssc.navy.mil","threadId":"21955","inReplyTo":"F25E4EFA-BDD8-4920-96FC-2347AD5A3605@silentcow.com","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2010-01-05T16:41:03Z","receivedAt":"2010-01-05T16:41:03Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"Jason King wrote:\n> I just grabbed 1.6.6 and noticed that this problem still exists. I just\n> wanted to ping this thread to make sure this hadn't been forgotten.\n\nI am interested in fixing this but have not been able to get to it.\n\n-brandon\n"},{"id":"134456","messageId":"A819F036-17D9-49C2-B3EC-85CFA27D30B8@silentcow.com","threadId":"21955","inReplyTo":"wtPFseZ4A1pT-STvrVsX7nC5hglK1gLCP4QZPtcSuvTN1jW0PYRUbQ@cipher.nrlssc.navy.mil","subject":"Re: am fails to apply patches for files with CRLF lineendings","fromName":"Jason King","fromEmail":"jk@silentcow.com","sentAt":"2010-02-13T19:07:25Z","receivedAt":"2010-02-13T19:07:25Z","isPatch":false,"sender":{"key":"jk@silentcow.com","avatar":null},"body":"Just noticed 1.7 was just tagged, so I thought I'd ping you guys about \nthis CRLF issue in `am` again - squeaky wheel sort of thing. Thanks :)\n\nOn Jan 5, 2010, at 8:41 AM, Brandon Casey wrote:\n\n> Jason King wrote:\n>> I just grabbed 1.6.6 and noticed that this problem still exists. I \n>> just\n>> wanted to ping this thread to make sure this hadn't been forgotten.\n>\n> I am interested in fixing this but have not been able to get to it.\n>\n> -brandon\n>\n"}]}