summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 54aae5e)
raw | patch | inline | side by side (parent: 54aae5e)
author | Antonio Ospite <ospite@studenti.unina.it> | |
Fri, 12 Nov 2010 14:55:08 +0000 (15:55 +0100) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Fri, 12 Nov 2010 21:44:26 +0000 (13:44 -0800) |
When an initial --in-reply-to is supplied, make it apply only to the
first message; --[no-]chain-reply-to setting are honored by second and
subsequent messages; this is also how the git-format-patch option with
the same name behaves.
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.
Look at the v2 series in the illustration to see what the new behavior
ensures:
(before the patch) | (after the patch)
[PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation | [PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation
This is the typical behaviour we want when we send a series with cover
letter in reply to some discussion, the new patch series should appear
as a separate subtree in the discussion.
Also update the documentation on --in-reply-to to describe the new
behavior.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
first message; --[no-]chain-reply-to setting are honored by second and
subsequent messages; this is also how the git-format-patch option with
the same name behaves.
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.
Look at the v2 series in the illustration to see what the new behavior
ensures:
(before the patch) | (after the patch)
[PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation | [PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation
This is the typical behaviour we want when we send a series with cover
letter in reply to some discussion, the new patch series should appear
as a separate subtree in the discussion.
Also update the documentation on --in-reply-to to describe the new
behavior.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-send-email.txt | patch | blob | history | |
git-send-email.perl | patch | blob | history | |
t/t9001-send-email.sh | patch | blob | history |
index 05904e0e7f31896191bc10224c09d14e91372952..ebc024ae3d6f48671858197d46ba74329e6b1b3f 100644 (file)
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.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+ 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.
++
+So for example when `--thread` and `--no-chain-reply-to` are specified, the
+second and subsequent patches will be replies to the first one like in the
+illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
++
+ [PATCH 0/2] Here is what I did...
+ [PATCH 1/2] Clean up and tests
+ [PATCH 2/2] Implementation
+ [PATCH v2 0/3] Here is a reroll
+ [PATCH v2 1/3] Clean up
+ [PATCH v2 2/3] New tests
+ [PATCH v2 3/3] Implementation
++
+Only necessary if --compose is also set. If --compose
+is not set, this will be prompted for.
--subject=<string>::
Specify the initial subject of the email thread.
diff --git a/git-send-email.perl b/git-send-email.perl
index f68ed5a5d3208eb0669d7dc1289f40c567e077c7..fe6b8485cd0c0781908cf83e377be048cfc0544b 100755 (executable)
--- a/git-send-email.perl
+++ b/git-send-email.perl
# 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 26c2e93c43724284382816916bc20c552c85bf3a..5e48318013a5bf0e4c0ab80f2e5cad6d96887e6a 100755 (executable)
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
--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 &&