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, this is what the man page says about the
--[no-]chain-reply-to option and this is also how the --in-reply-to
option behaves in git-format-patch.
Moreover, when $initial_reply_to is asked to the user interactively it
is asked as the "Message-ID to be used as In-Reply-To for the _first_
email", this makes the user think that the second and subsequent patches
are not using it but are considered as replies to the first message or
chained according to the --[no-]chain-reply setting.
Adjust also the documentation about --in-reply-to to avoid ambiguities.
NOTE: This patch changes the current behaviour and brings it to be what
I think was the intentions stated in the documentation, also aligning it
to how git-format-patch behaves; in order to achieve the old behaviour
of a flat structure in reply to something the user can always use
"--no-thread --in-reply-to <...>".
Signed-off-by: Antonio Ospite <ospite@xxxxxxxxxxxxxxxxx>
---
Changes since v2:
- Make the purpose of the patch more explicit
- Adjust the documentation
- Make the test narrower and more explicit as well
I am CCing some of the latest contributors to git-send-email.perl
Juno, there are still some unanswered questions (one about the
and-chains in tests) in one of previous mails in this thread.
With Best Regards,
Antonio
Documentation/git-send-email.txt | 8 +++++---
git-send-email.perl | 3 ++-
t/t9001-send-email.sh | 14 ++++++++++++++
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 05904e0..acbff9b 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -82,9 +82,11 @@ See the CONFIGURATION section for 'sendemail.multiedit'.
set, as returned by "git var -l".
--in-reply-to=<identifier>::
- Specify the contents of the first In-Reply-To header.
- Subsequent emails will refer to the previous email
- instead of this if --chain-reply-to is set.
+ Make the first mail (or all the mails with `--no-thread`) appear as a
+ reply to the given Message-Id, which avoids breaking threads to
+ provide a new patch series.
+ The second and subsequent emails will be sent as replies according to
+ the --[no]-chain-reply-to setting.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
diff --git a/git-send-email.perl b/git-send-email.perl
index f68ed5a..fe6b848 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1319,7 +1319,8 @@ foreach my $t (@files) {
# set up for the next message
if ($thread && $message_was_sent &&
- (chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {
+ (chain_reply_to() || !defined $reply_to || length($reply_to) == 0 ||
+ $message_num == 1)) {
$reply_to = $message_id;
if (length $references > 0) {
$references .= "\n $message_id";
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index d1ba252..c85be0f 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -313,6 +313,20 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '
! grep "^In-Reply-To: < *>" msgtxt1
'
+test_expect_success $PREREQ 'Apply initial In-Reply-To only to first patch with --thread' '
+ clean_fake_sendmail &&
+ git send-email \
+ --from="Example <nobody@xxxxxxxxxxx>" \
+ --to=nobody@xxxxxxxxxxx \
+ --thread \
+ --in-reply-to="<unique-message-id@xxxxxxxxxxx>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $patches $patches \
+ 2>errors
+ # The second message should not have the initial In-Reply-To
+ test $(sed -n -e "s/^In-Reply-To: \(.*\)/\1/p" msgtxt2) != "<unique-message-id@xxxxxxxxxxx>"
+'
+
test_expect_success $PREREQ 'setup fake editor' '
(echo "#!$SHELL_PATH" &&
echo "echo fake edit >>\"\$1\""
--
1.7.2.3
--
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