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

Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:

I think the fundamental problem is that what MUA uses as the internal storage format doesn't necessarily have to even be RFC-2822, which only specifies what should be on-the-wire. The blamed commit took things too far.

It actually is the norm to use LF as the line terminator in the body text in saved messages (and trailing CR as a true part of the payload), and "am" traditionally used that definition. It is meant to read from "mbox" format to begin with.

Before the blamed commit, "am" took what was given literally, and it treated the trailing CR as part of the payload in a text file, each of whose line is LF terminated. This meant that if you sent and your MUA didn't corrupt, or more importantly if you ran format-patch yourself to produce a patch on content with CRLF line endings and fed it to am without any e-mail involved, your CRLF would have been preserved. So in that sense, unlike what you said in your message, the blamed commit didn't decide that the line termination must be LF. It decided that the line termination does not matter, which is a lot worse.

As long as the use of CR is an internal storage matter and "Save As..." doesn't add extra CR that wasn't in the original contents, I wouldn't say that such a MUA is broken. In the use case that led to the blamed commit, the user is choosing to read directly from the internal storage of MUA, bypassing its "Save As..." interface meant to be used to externalize the messages, and the user is responsible for dealing with the fallout, hence my "dos2unix" suggestion in the original thread.

Probably we should revert that commit, unless somebody comes up with a better solution _or_ somebody convincingly argues that there shouldn't be CRLF in your committed history.