On 06/17/2011 10:50 AM, Jeff King wrote: > On Fri, Jun 17, 2011 at 10:37:54AM -0500, Brandon Casey wrote: > >>>> $ git format-patch --stdout --keep-subject --attach origin | git imap-send >> >> Wait a second. You used --attach. >> >>>> 2. Open Gmail in Chrome. >>>> 3. Open email in drafts folder. >>>> 4. Click attachment download link >> >> Then you downloaded the attachment, which should be a _patch_. > > Yeah, but if it is text/*, It is. > then according to rfc2046, it must be > represented with CRLF as the line break. And especially if we are > including it unencoded in a message, it is going to need CR's added. > >>>> 5. Apply patch on a fresh branch with git apply. >> >> Well, scratch what I said before, you were correct in using >> git apply. >> >> Shouldn't the attachment have it's content preserved exactly? Maybe >> the fault does belong to gmail. > > Is it gmail's fault, or the browser's? If gmail is handing back a > text/* content-type, then my reading of rfc2046 is that it should have > CRLF line breaks. And it would be the browser's responsibility to > convert to native line endings. But that's the MIME spec, and was > written with mail in mind; I don't know what's normal for HTTP in these > situations. But if the problem is not "strip CR" but "convert to native > line endings" (which I think it is), then how could gmail know the > user's native line ending preference, anyway? So it's the same issue of line ending ambiguity that affects patches sent inline in the body of the email message. What we really want is the _original_ line ending, not necessarily the native line ending of the platform, but since any text/* content returned from or sent to the mail server must have CRLF line endings, it is impossible to determine whether or not the original content really had LF line endings or not. Currently, mailsplit chooses to assume the original line ending was LF, based on the assumption that that's the line ending that most projects use. There doesn't seem to be any advantage to using --attach then, over just including the patch inline. Maybe attachments should always be base64 encoded? I get the eerie feeling that this topic has already been hashed to death. -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