Forwarding to the list. The original was bounced since gmail sent a multipart mime version with html. Seems we can't disable html composing in the gmail settings anymore (I thought we used to be able to). ---------- Forwarded message ---------- From: Brandon Casey <drafnel@xxxxxxxxx> Date: Mon, Dec 14, 2009 at 6:50 PM Subject: Re: am fails to apply patches for files with CRLF lineendings To: Junio C Hamano <gitster@xxxxxxxxx> Cc: Brandon Casey <brandon.casey.ctr@xxxxxxxxxxxxxxx>, Björn Steinbrink <B.Steinbrink@xxxxxx>, jk@xxxxxxxxxxxxx, git@xxxxxxxxxxxxxxx On Mon, Dec 14, 2009 at 5:22 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Brandon Casey <brandon.casey.ctr@xxxxxxxxxxxxxxx> writes: > > > My understanding of the problem is that rfc2822 dictates that... > > 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. If CRLF is what is on-the-wire, how can the MUA tell whether the original was also CRLF or whether it was only LF? My assumption was that the MUA cannot tell, and that things worked for most people because those people who wanted LF terminated output were on platforms that used LF termination and their MUA produced output using the native line termination. Things broke recently for some people since thunderbird devels decided to start saving emails with CRLF termination on linux. > > 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. But isn't each email in the mbox file supposed to be RFC-2822 formatted anyway? If so, then my reading of RFC-2822 says that there should only be CRLF everywhere and no bare CR or bare LF. But maybe everyone has just been ignoring that part of RFC-2822? I'm not an email expert, so I really don't know. > > 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. I think it is more correct to say that the line termination in an email is ambiguous. CRLF does not necessarily mean that the original had CRLF line termination if RFC-2822 is followed explicitly. > 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, No, we're using "Save As..." in thunderbird, and it saves with CRLF line endings. I don't really care for thunderbird and its proclivity for munging my emails and _not_ doing-the-right-thing in my opinion. Maybe someone can suggest a mail client that can use imap and provide the nice sorting of emails into folders like thunderbird does. -brandon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html