Re: MIME headers in introductory message (git send-email --compose)

"Jay Soffian" [off-list ref] writes:

I stuck this in my config and it works-for-me:

[format]
	headers = \
"MIME-Version: 1.0\n\
Content-Type: text/plain; charset=UTF-8\n\
Content-Transfer-Encoding: 8bit\n"

I suspect that you shouldn't do this.  This would badly interfere both
with existing format-patch behaviour that adds these MIME-Version and
Content-Type headers by looking at the contents, and with recent
format-patch fix 6bf4f1b (format-patch: generate MIME header as needed
even when there is format.header, 2008-03-14) to make the detection based
on contents (and presense of format.headers).

On Tue, Mar 25, 2008 at 4:47 PM, Junio C Hamano [off-list ref] wrote:

"Jay Soffian" [off-list ref] writes:

 > I stuck this in my config and it works-for-me:
 >
 > [format]
 >       headers = \
 > "MIME-Version: 1.0\n\
 > Content-Type: text/plain; charset=UTF-8\n\
 > Content-Transfer-Encoding: 8bit\n"

 I suspect that you shouldn't do this.  This would badly interfere both
 with existing format-patch behaviour that adds these MIME-Version and
 Content-Type headers by looking at the contents, and with recent
 format-patch fix 6bf4f1b (format-patch: generate MIME header as needed
 even when there is format.header, 2008-03-14) to make the detection based
 on contents (and presense of format.headers).

Fair enough. But I never send out a patch w/o looking at it in an editor
first so I would've caught that. Thanks for the heads-up though.

j.

On Tue, Mar 25, 2008 at 01:47:05PM -0700, Junio C Hamano wrote:

quoted

I stuck this in my config and it works-for-me:

[format]
	headers = \
"MIME-Version: 1.0\n\
Content-Type: text/plain; charset=UTF-8\n\
Content-Transfer-Encoding: 8bit\n"

I suspect that you shouldn't do this.  This would badly interfere both
with existing format-patch behaviour that adds these MIME-Version and
Content-Type headers by looking at the contents, and with recent
format-patch fix 6bf4f1b (format-patch: generate MIME header as needed
even when there is format.header, 2008-03-14) to make the detection based
on contents (and presense of format.headers).

Yes, I can confirm that that is problematic without even testing.  The
whole point of 6bf4f1b was that we _should_ add MIME headers even if the
user has set format.headers.

We could be more clever about parsing format.headers and mark the "we
have already added MIME" flag (I think we already have to do such
parsing because of to/cc magic). But I have to wonder what the real goal
is here. There has sometimes been a call for "please add MIME headers
unconditionally"; maybe that is an option that people would like.

-Peff

On Tue, Mar 25, 2008 at 05:56:14PM -0400, Jeff King wrote:

We could be more clever about parsing format.headers and mark the "we
have already added MIME" flag (I think we already have to do such
parsing because of to/cc magic). But I have to wonder what the real goal

I started on this out of curiosity, and it _is_ really simple, but it's
also wrong.  It can't be right to set your MIME headers statically
because some options (like --attach) might cause us to have to put in
_different_ MIME headers. So we are left with either conflicting
headers, disallowing --attach, ignoring some of your format.headers, or
possibly picking out those headers and making them part of the header of
that patch part of the multipart. All of which seem a bit ugly to me.

If this is something people really want, I think just adding an "always
add mime headers" option makes the most sense.

-Peff