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/*, 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? -Peff -- 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