Hi André, André Goddard Rosa wrote: >> I'm not using any specific tool for inputting the git-format-patch, >> but instead I'm sending the files generated by it through gmail as an >> inlined patch in the email body. >> >> I like the convenience of format-patch for generating the patch files, >> but in this case, formatting the header as rfc2047 is not necessary >> and makes a funny/garbled output in my patch submission. The header fields git format-patch outputs are just intended as a starting point for the header of your mailing. It is more convenient to receive an e-mail with Delivered-to: maintainer@xxxxxxxxxxx Received: [...] Message-ID: <patch.sender.0001@xxxxxxxxxxx> Date: Tue, 03 Nov 2009 16:33:54 -0600 From: Patch Sender <patch.sender@xxxxxxxxxxx> Subject: [PATCH] Fix one bug, add another Content-Type: text/plain; charset=us-ascii Blah blah blah than one in which the content includes some useless metadata that was already in the header. So you should just strip the header out from the body before sending. There are three common exceptions: 1) you might want to send a patch written by someone else, 2) you might want to mark a patch as written before it was sent, and 3) some people like to receive patches as attachments rather than inlined in messages. For the first two cases, the solution is to include the header fields to change in the body: From: Patch Writer <patch.writer@xxxxxxxxxxx> Date: Wed, 01 Apr 1970 01:23:45 +0100 Blah blah blah --- Hi, Patch Writer wrote this patch a while ago that might be relevant. It needed a straightforward one-line change to apply and is otherwise unchanged. What do you think? [...] For the last case, I think it is most common to send unchanged 'git format-patch' output. But only the From, Date, and Subject fields are actually needed. I am not sure how well 'git am' copes with non-ascii characters in the pseudo-header lines: I would have guessed it could handle them both rfc2047-encoded and not, but I have not tried. > I really would like continuing having the convenience of using a web > access to my gmail for sending the patches, so I just need a way to > format the patches which makes it easy submitting them later. I'd like > to avoid using any other email client for that, if possible. Here, there is another danger: the Gmail web interface does not consider your whitespace precious, so it is very prone to mangling patches (especially with long lines). Documentation/SubmittingPatches [1] has some advice: | Gmail | ----- | | GMail does not appear to have any way to turn off line wrapping in the web | interface, so this will mangle any emails that you send. You can however | use any IMAP email client to connect to the google imap server, and forward | the emails through that. Just make sure to disable line wrapping in that | email client. Alternatively, use "git send-email" instead. | | Submitting properly formatted patches via Gmail is simple now that | IMAP support is available. First, edit your ~/.gitconfig to specify your | account settings: | | [imap] | folder = "[Gmail]/Drafts" | host = imaps://imap.gmail.com | user = user@xxxxxxxxx | pass = p4ssw0rd | port = 993 | sslverify = false | | You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error | that the "Folder doesn't exist". | | Next, ensure that your Gmail settings are correct. In "Settings" the | "Use Unicode (UTF-8) encoding for outgoing messages" should be checked. | | Once your commits are ready to send to the mailing list, run the following | command to send the patch emails to your Gmail Drafts folder. | | $ git format-patch -M --stdout origin/master | git imap-send | | Go to your Gmail account, open the Drafts folder, find the patch email, fill | in the To: and CC: fields and send away! Good luck. Hope that helps, Jonathan [1] <http://git.kernel.org/?p=git/git.git;a=blob_plain;f=Documentation/SubmittingPatches> converting tabs to spaces. -- 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