Re: [PATCH] allow 8bit data in email body sent by send-email

From: Jeff King <peff@peff.net>
Date: Jan 9, 2009, 14:44 UTC
Message-ID: <20090109144403.GA12994@coredump.intra.peff.net>
In-Reply-To: <49675C38.8060208@amd.com>

On Fri, Jan 09, 2009 at 03:16:24PM +0100, Andre Przywara wrote:

Show 5 quoted lines

>> This should be done already by git-format-patch when you generate the
>> patch to feed to send-email.
> Well, this could be discussed, after all the problem lies in the actual  
> transportation, which should be the responsibility of git-send-email. But 
> I am OK with putting this into format-patch.

I didn't mean "this functionality should go into format-patch" but rather "this functionality is _already_ in format-patch, and it should have been triggered".

The reason it has to be in format-patch is that only format-patch knows what the correct encoding is. It's not that useful to just say "oh, this is some 8-bit data." You also want to give a content-type header that specifies the correct encoding. And anything that contains non-ascii characters should come out of format-patch with such a header.

Show 6 quoted lines

> > What exactly is the workflow you use to generate this problem?
> I use git format-patch to generate a patch file for a single-mail patch  
> (not a patch series). Then I edit this file manually to add questions and 
> comments and include my signature. During this step the umlauts came in. 
> If you have a suggestion to improve this workflow, I am all ears, I am 
> fairly new to git.

Ah, I see. I'm not sure what the best solution is there. send-email has intentionally been kept pretty dumb, because implementing full MUA behavior would make it pretty unwieldy. You could add an option to send-email to add the 8-bit transfer-encoding header if necessary, but it will have to guess at (or be configured to know) the correct encoding of the characters.

Personally, when I want to add information like that to a patch, I pull the output of format-patch into my MUA (mutt, in my case). I don't know if that is a workable solution for you.

> Ok, so what about adding a flag to git-format-patch that forces the 8bit  
> headers on? I think a workaround would be to add a --subject-prefix with  
> a special character and later remove this, but this is not really a  
> long-term solution ;-)

Now that you've explained your workflow, I do think send-email is a more appropriate place to add a header, since format-patch never even sees the data that is causing the problem. Probably the sanest thing would be to check each input file for non-ascii characters. If they are found, and the message does not already have some MIME headers, then add an 8bit content-transfer-encoding and a text/plain content-type. In the latter, you would need to specify some encoding. Most of git defaults to utf-8, but it should probably be configurable.

We have to do a similar thing for the --compose option, so looking at what that does is probably a good starting point.

-Peff