Re: git imap-send converting my patches to CRLF line endings?

[Michael Mc Donnell <michael@mcdonnell.dk>]

On Fri, Jun 17, 2011 at 6:54 PM, Brandon Casey
<brandon.casey.ctr@nrlssc.navy.mil> 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?