Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:49:49
Possibly related (same subject, not in this thread)
- 2016-06-15 · [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches · Antonio Ospite <hidden>
- 2016-06-15 · Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches · Junio C Hamano <hidden>
Antonio Ospite [off-list ref] writes:
Make second and subsequent patches appear as replies to the first patch, even when an initial In-Reply-To is supplied; this is the typical behaviour we want when we send a series with cover letter in reply to some discussion, and this is also what the man page says about the --in-reply-to option.
I am not so sure if that is what the documentation says.
1. When --in-reply-to gives $reply_to, the first one becomes a reply to
that message, with or without --chain-reply-to.
2. When --chain-reply-to is in effect, all the messages are strung
together to form a single chain. The first message may be in reply to
the $reply_to given by --in-reply-to command line option (see
previous), or the root of the discussion thread. The second one is a
response to the first one, and the third one is a response to the
second one, etc.
3. When --chain-reply-to is not in effect:
a. When --in-reply-to is used, too, the second and the subsequent ones
become replies to $reply_to. Together with the first rule, all
messages become replies to $reply_to given by --in-reply-to.
b. When --in-reply-to is not used, presumably the second and
subsequent ones become replies to the first one, which would be the
root.
The documentation is reasonably clear about the 1., 2. and 3a. above, I
think, even though I do not think 3b. is clearly specified.
If you are changing 3a. above so that the first message becomes a response
to $reply_to, and the second one becomes a response to the first message
(and the third and subsequent ones too when --chain-reply-to is not in
effect), you would need to update the documentation as well. Even if it
might be of good kind, it would be a change of the established behaviour.
quoted hunk
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh index a298eb0..410b85f 100755 --- a/t/t9001-send-email.sh +++ b/t/t9001-send-email.sh@@ -295,6 +295,20 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' ' ! grep "^In-Reply-To: < *>" msgtxt1 ' +test_expect_success $PREREQ 'In-Reply-To in second patch with --thread' ' + clean_fake_sendmail && + git send-email \ + --from="Example <nobody@example.com>" \ + --to=nobody@example.com \ + --thread \ + --in-reply-to="<unique-message-id@example.com>" \ + --smtp-server="$(pwd)/fake.sendmail" \ + $patches $patches \ + 2>errors
You are breaking the && chain here.
+ # The second patch should be seen as reply to the first one + test $(sed -n -e "s/^In-Reply-To:\(.*\)/\1/p" msgtxt2) = $(sed -n -e "s/^Message-Id:\(.*\)/\1/p" msgtxt1) +'
You would need to test the interaction with --chain-reply-to as well, so there should be another test, and you would probably need three messages fed to send-email not just two to see the effect of the interaction. Thanks.