Re: am fails to apply patches for files with CRLF lineendings

From: Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>
Date: Dec 14, 2009, 22:56 UTC
Message-ID: <tCQlJn153g8Oa6Z9HKe6xOUQJdcf2PCIVthlTrLgYE-wJ5jFyXVXWw@cipher.nrlssc.navy.mil>
In-Reply-To: <7vvdg9i9mn.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 15 quoted lines

> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> 
>> Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF line-endings"
>> seems to be responsible.
> 
> Yes, that commit is not only responsible but was deliberate.  For a better
> backstory, see:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
> 
> You'd notice that I was one of the people who didn't want to have this
> change, so you don't need to convince _me_ that this was not a change to
> keep everybody happy, but you'd need to try a better job than I did back
> then to convince people who thought that "am" should directly work on
> "Thunderbird saved mails" that what they want was a bad idea X-<.

My understanding of the problem is that rfc2822 dictates that CRLF is the line ending in an email message for _every_ line, and that CR cannot occur without LF and vice versa. So there is no reliable way to extract patches from the body of an email and expect line endings to be conveyed accurately. Some email clients save emails with the line-endings of the platform, some save in what they call "raw" format with rfc2822's CRLF line endings. So we have to _assume_ that the patch extracted from the email has a particular line ending and make-it-so. For better or worse (better for me), commit c2ca1d7 chose LF line-endings as the line-ending of choice.

I agree that git-am should be able to apply everything that git-format-patch produces. Perhaps the diff machinery should be modified to treat files containing \r as binary when generating the output for format-patch. Then we'd get a binary diff in the email.

-brandon