Re: Creating attachments using git-format-patch

Hi,

On Sun, Mar 04, 2007 at 01:33:09PM -0800, Junio C Hamano wrote:

Panagiotis Issaris [off-list ref] writes:

quoted

The patch did not work for me in the sense that the patches still 
appeared as inline text in both Mutt (1.5.13) and Thunderbird (2 beta 2).

The email show up as being threaded in Mutt, but in Thunderbird they 
still do not show up threaded.
thread about git-format-patch attachments, so Thunderbird appears to 
work alright).

If the patch below is needed, then I doubt you can honestly say
it appears to work...

Well, here on Ubuntu using Mutt and Thunderbird the change below indeed makes
the patches appear as attachments instead of inline text.

The e-mails not showing up as one thread is probably some other issue, or some
misuse of me of git-format-patch and git-send-email.

I'm trying to get one e-mail sent with a header of [PATCH 00/16] with the other
patches as attachments to that one summary e-mail. Initially they did not show
up as being threaded in Thunderbird, but they did show up being threaded in
Mutt. Now, with some experimentation, I managed to get them to show up in a
thread in Thunderbird too, but unfortunately, now I am seeing the [PATCH 00/16]
e-mail followed by one reply [PATCH 01/16] and all others are replies to [PATCH
01/16] instead of [PATCH 00/16]. Or by further experimentation, I got the [PATCH
00/16] e-mail sent with 14 replies correctly threaded, but two of them for some
reader not ending up in the same thread...

git-format-patch --thread --attach -n origin..or2

git-send-email --no-chain-reply-to --to takis.issaris@uhasselt.be --from \
takis@issaris.org --subject "[PATCH 00/16] Various Doxygen related patches" \
--suppress-from --compose 00*patch

I've tried removing the --no-chain-reply and removing the --thread option of
format-patch, but I never manage to get the mails sent in the way I want them
to.

Anyway, I think my not-showing-up-as-a-thread issue is mainly because of me not
understanding how to use it correctly :) and being unrelated to the
patches-showing-up-inline-instead-of-as-attachments issue, which is really fixed
here with the patch shown below.

In fact, I noticed that using --inline or --attach does not seem to make a
difference for Mutt or Thunderbird, in both cases the emails appear to have
attachments now :-/

The way I came to the patch below is by manually editing the e-mails generated
by git-format-patch and sending them after each modification with git-send-email
until I figured out what change made the patches appear as attachments in both
email clients.

quoted

diff -u b/log-tree.c b/log-tree.c

--- b/log-tree.c
+++ b/log-tree.c

@@ -186,7 +186,7 @@
 			snprintf(subject_buffer, sizeof(subject_buffer) - 1,
 				 "%s"
 				 "MIME-Version: 1.0\n"
-				 "Content-Type: multipart/mixed;\n"
+				 "Content-Type: multipart/mixed;"
 				 " boundary=\"%s%s\"\n"
 				 "\n"
 				 "This is a multi-part message in MIME "

@@ -202,10 +202,10 @@
 
 			snprintf(buffer, sizeof(buffer) - 1,
 				 "--%s%s\n"
-				 "Content-Type: text/x-patch;\n"
+				 "Content-Type: text/x-patch;"
 				 " name=\"%s.diff\"\n"
 				 "Content-Transfer-Encoding: 8bit\n"
-				 "Content-Disposition: %s;\n"
+				 "Content-Disposition: %s;"
 				 " filename=\"%s.diff\"\n\n",
 				 mime_boundary_leader, opt->mime_boundary,
 				 sha1,

But if it helps some implementations of MIME decoder without
harming others, then I'd say why not.  I just wanted to make
sure it does not throw regression at others (for example by
making the physical line too long for them to grok).

Of course, I fully understand your cautiousness.

With friendly regards,
Takis