On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote: > ... Yes. But actually, the Content-Type header is from > git-format-patch: > > $ git format-patch --stdout 12806b^..12806b |head > From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001 > From: Johannes Schindelin <Johannes.Schindelin@xxxxxx> > Date: Thu, 10 May 2007 12:36:15 +0200 > Subject: [PATCH] Add a birdview-on-the-source-code section to the user > manual > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit Ah, interesting. I had checked that, but my test didn't produce those headers. It seems we only produce them if there are non-ascii characters in the commit message (and I just checked with an arbitrary commit). So really, this (totally untested) one-liner should fix it: diff --git a/commit.c b/commit.c index 922437f..5669c2f 100644 --- a/commit.c +++ b/commit.c @@ -1065,6 +1065,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt, int sz; char header[512]; const char *header_fmt = + "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=%s\n" "Content-Transfer-Encoding: 8bit\n"; sz = snprintf(header, sizeof(header), header_fmt, Providing that nobody objects to sticking that extra header in format-patch's output (but of course only when we actually have non-ascii data). It's technically required if we want the output to be a valid MIME message, but most things are unlikely to care (except vger's apparently picky MTA). -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
