On Fri, Jun 17, 2011 at 6:54 PM, Brandon Casey <brandon.casey.ctr@xxxxxxxxxxxxxxx> wrote: > 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. It sounds like its a big job to implement all those RFCs correctly. Is there a library that could be used for handling imap? -- 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