Antonio Ospite [off-list ref] writes:
When an initial In-Reply-To is supplied it should apply only to the
first email, second and subsequent messages should behave just according
to the --[no-]chain-reply-to setting; this is the typical behaviour we
want when we send a series with cover letter in reply to some
discussion,
+1 on this. I've been biten by this behavior sending the v2 of
a patch serie --in-reply-to the cover letter for the v1. The two
versions of each patch appear as reply to the original cover letter,
it's kind of a mess. I was really expecting the patch serie to appear
as a separate subtree in the discussion.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Matthieu Moy [off-list ref] writes:
I've been biten by this behavior sending the v2 of
a patch serie --in-reply-to the cover letter for the v1. The two
versions of each patch appear as reply to the original cover letter,
it's kind of a mess. I was really expecting the patch serie to appear
as a separate subtree in the discussion.
The above is much better description of what issue the patch is trying to
address; something like that should go to the description.
Antonio, I've already queued a few tests that document the established
behaviour on ao/send-email-irt branch (54aae5e1), so could you rebase your
patch on it, perhaps with an updated explanation in the log (and in the
documentation)?
Thanks, both.
On Tue, 09 Nov 2010 13:23:07 -0800
Junio C Hamano [off-list ref] wrote:
Matthieu Moy [off-list ref] writes:
quoted
I've been biten by this behavior sending the v2 of
a patch serie --in-reply-to the cover letter for the v1. The two
versions of each patch appear as reply to the original cover letter,
it's kind of a mess. I was really expecting the patch serie to appear
as a separate subtree in the discussion.
The above is much better description of what issue the patch is trying to
address; something like that should go to the description.
Alright, I'll try mentioning the actual use case too.
Antonio, I've already queued a few tests that document the established
behaviour on ao/send-email-irt branch (54aae5e1), so could you rebase your
patch on it, perhaps with an updated explanation in the log (and in the
documentation)?
Junio, ao/send-email-irt seems to have been merged into origin/next, so
I am rebasing on that. About the tests, I am going to modify one of your
tests instead of adding another one, is that OK? This is a change of the
established behavior after all, so the relative test have to change too,
something along these lines:
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 66e4852..c56787f 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -324,9 +324,11 @@ test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '
--smtp-server="$(pwd)/fake.sendmail" \
$patches $patches $patches \
2>errors &&
- # All the messages are replies to --in-reply-to
+ # The first message is a reply to --in-reply-to
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt1 >actual &&
test_cmp expect actual &&
+ # Second and subsequent messages are replies to the first one
+ sed -n -e "s/^Message-Id: *\(.*\)/\1/p" msgtxt1 >expect &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt2 >actual &&
test_cmp expect actual &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt3 >actual &&
Let me just stress out that 3a. as in 54aae5e1 is not well specified
either, that's what all this fuss is about. I notice you didn't comment
about my view of the "independence" of the --in-reply-to setting wrt.
--[no-]chain-reply-to but I guess that falls into the implicit/explicit
debate, so I am not pushing it and just follow your directions about
explicitly relating the two.
Thanks, both.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?