{"thread":{"id":"25443","subject":"[PATCH] git-send-email.perl: fix In-Reply-To for second and subsequent patches","startedAt":"2010-10-14T09:38:58Z","lastAt":"2010-11-12T22:51:00Z","messageCount":19,"participants":["Antonio Ospite","Jonathan Nieder","Junio C Hamano","Matthieu Moy"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"153505","messageId":"1287049138-13940-1-git-send-email-ospite@studenti.unina.it","threadId":"25443","inReplyTo":null,"subject":"[PATCH] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-10-14T09:38:58Z","receivedAt":"2010-10-14T09:38:58Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"Make second and subsequent patches appear as replies to the first patch,\neven when an initial In-Reply-To is supplied; this is the typical\nbehaviour we want when we send a series with cover letter in reply to\nsome discussion, and this is also what the man page says about\n--in-reply-to.\n\nIn order to achieve the old behaviour of a flat structure in reply to\nsomething the user can always use \"--no-thread --in-reply-to <...>\".\n\nSigned-off-by: Antonio Ospite \n\n---\n\nHi,\n\nRight now _all_ the patches appear as reply to the message indicated as\ninitial In-Reply-To, and I think this is not right, the behaviour this\npatch introduces can be debatable of course, but there are quite some\narguments supporting it:\n\n - When $initial_reply_to is asked to the user, it is asked as the\n \"Message-ID to be used as In-Reply-To for the _first_ email\", this\n makes me think that the second and subsequent patches are not using\n it and will be considered as reply to the first message or chained\n according to the --[no-]chain-reply-to setting.\n\n - git-format-patch states that clearly in the man page, and I think\n git-send-email should behave the same way, and this is explained\n also in the git-send-email man page, look at\n --in-reply-to= explanation.\n\nPlease keep CCing me on this as I am not subscribed to git@vger.kernel.org.\n\nThanks,\n Antonio Ospite\n http://ao2.it\n\n\n git-send-email.perl | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 8cc4161..615a40d 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1313,7 +1313,7 @@ foreach my $t (@files) {\n \n \t# set up for the next message\n \tif ($thread && $message_was_sent &&\n-\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n+\t\t($message_num == 1 || chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n \t\t$reply_to = $message_id;\n \t\tif (length $references > 0) {\n \t\t\t$references .= \"\\n $message_id\";\n-- \n1.7.1\n"},{"id":"153528","messageId":"20101014182250.GA18341@burratino","threadId":"25443","inReplyTo":"1287049138-13940-1-git-send-email-ospite@studenti.unina.it","subject":"Re: [PATCH] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-14T18:22:50Z","receivedAt":"2010-10-14T18:22:50Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: some send-email people)\n\nHi,\n\nAntonio Ospite wrote:\n\n> Make second and subsequent patches appear as replies to the first patch,\n> even when an initial In-Reply-To is supplied\n[...]\n> Signed-off-by: Antonio Ospite \n\nThanks.\n\n> - When $initial_reply_to is asked to the user, it is asked as the\n> \"Message-ID to be used as In-Reply-To for the _first_ email\", this\n> makes me think that the second and subsequent patches are not using\n> it\n\nThis kind of justification belongs in the commit message, no?\nThat way, we can save future readers the trouble of figuring out\nthe rationale all over again when considering future changes to this\ncode.\n\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -1313,7 +1313,7 @@ foreach my $t (@files) {\n> \n> \t# set up for the next message\n> \tif ($thread && $message_was_sent &&\n> -\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n> +\t\t($message_num == 1 || chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n> \t\t$reply_to = $message_id;\n\nWould it be possible to break this long line?\n\nIf you're feeling particularly adventurous, it would be nice to add a\ntest for the changed functionality to t/t9001-send-email.sh, so we\ndon't break it with other changes in the future.\n\nI haven't looked too deeply or even tried running applying the patch,\nbut generally it looks good to me.\n\nCiao,\nJonathan\n"},{"id":"153567","messageId":"20101015095651.b75c4b54.ospite@studenti.unina.it","threadId":"25443","inReplyTo":"20101014182250.GA18341@burratino","subject":"Re: [PATCH] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-10-15T07:56:51Z","receivedAt":"2010-10-15T07:56:51Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"On Thu, 14 Oct 2010 13:22:50 -0500\nJonathan Nieder wrote:\n\n> (+cc: some send-email people)\n>\n\nFor the new recipients, the original mail is here btw:\nhttp://permalink.gmane.org/gmane.comp.version-control.git/159039\n\nMore comments below.\n\n> Hi,\n> \n> Antonio Ospite wrote:\n> \n> > Make second and subsequent patches appear as replies to the first patch,\n> > even when an initial In-Reply-To is supplied\n> [...]\n> > Signed-off-by: Antonio Ospite \n> \n> Thanks.\n>\n\nThanks for commenting Jonathan.\n\n> > - When $initial_reply_to is asked to the user, it is asked as the\n> > \"Message-ID to be used as In-Reply-To for the _first_ email\", this\n> > makes me think that the second and subsequent patches are not using\n> > it\n> \n> This kind of justification belongs in the commit message, no?\n> That way, we can save future readers the trouble of figuring out\n> the rationale all over again when considering future changes to this\n> code.\n>\n\nOk, I can add this in the commit message, I am waiting some days for\nv2, in case someone else has more to say.\n\n> > --- a/git-send-email.perl\n> > +++ b/git-send-email.perl\n> > @@ -1313,7 +1313,7 @@ foreach my $t (@files) {\n> > \n> > \t# set up for the next message\n> > \tif ($thread && $message_was_sent &&\n> > -\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n> > +\t\t($message_num == 1 || chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n> > \t\t$reply_to = $message_id;\n> \n> Would it be possible to break this long line?\n>\n\nI like the OR chain on the same line, but I can split it anyways if\nthat's the preference.\n\n> If you're feeling particularly adventurous, it would be nice to add a\n> test for the changed functionality to t/t9001-send-email.sh, so we\n> don't break it with other changes in the future.\n>\n\nNo promises, but I might give that a try.\n\n> I haven't looked too deeply or even tried running applying the patch,\n> but generally it looks good to me.\n> \n> Ciao,\n> Jonathan\n> \n\nThanks,\n Antonio\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"},{"id":"153778","messageId":"1287481964-8883-1-git-send-email-ospite@studenti.unina.it","threadId":"25443","inReplyTo":"20101015095651.b75c4b54.ospite@studenti.unina.it","subject":"[PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-10-19T09:52:44Z","receivedAt":"2010-10-19T09:52:44Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"Make second and subsequent patches appear as replies to the first patch,\neven when an initial In-Reply-To is supplied; this is the typical\nbehaviour we want when we send a series with cover letter in reply to\nsome discussion, and this is also what the man page says about\nthe --in-reply-to option.\n\nWhen $initial_reply_to is asked to the user interactively it is asked as\nthe \"Message-ID to be used as In-Reply-To for the _first_ email\", this\nmakes the user think that the second and subsequent patches are not\nusing it but are considered as replies to the first message or chained\naccording to the --[no-]chain-reply setting.\n\nIn order to achieve the old behaviour of a flat structure in reply to\nsomething the user can always use \"--no-thread --in-reply-to <...>\".\n\nSigned-off-by: Antonio Ospite \n---\n\nChanges since v1:\n - add more details about the interactive case in the commit message\n - split long line as requested by Jonathan Nieder\n - add a test case in t/t9001-send-email.sh, please check that, I am not\n comparing the strings inside '<>' is it necessary to be so strict?\n Note to self: remember to run 'make' before running t9001-send-email.sh :)\n\nThanks,\n Antonio Ospite\n http://ao2.it\n\n git-send-email.perl | 3 ++-\n t/t9001-send-email.sh | 14 ++++++++++++++\n 2 files changed, 16 insertions(+), 1 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 8cc4161..bc4e318 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1313,7 +1313,8 @@ foreach my $t (@files) {\n \n \t# set up for the next message\n \tif ($thread && $message_was_sent &&\n-\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n+\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0 ||\n+\t\t$message_num == 1)) {\n \t\t$reply_to = $message_id;\n \t\tif (length $references > 0) {\n \t\t\t$references .= \"\\n $message_id\";\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex a298eb0..410b85f 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -295,6 +295,20 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '\n \t! grep \"^In-Reply-To: < *>\" msgtxt1\n '\n \n+test_expect_success $PREREQ 'In-Reply-To in second patch with --thread' '\n+\tclean_fake_sendmail &&\n+\tgit send-email \\\n+\t\t--from=\"Example \" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--thread \\\n+\t\t--in-reply-to=\"\" \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t$patches $patches \\\n+\t\t2>errors\n+ # The second patch should be seen as reply to the first one\n+ test $(sed -n -e \"s/^In-Reply-To:\\(.*\\)/\\1/p\" msgtxt2) = $(sed -n -e \"s/^Message-Id:\\(.*\\)/\\1/p\" msgtxt1)\n+'\n+\n test_expect_success $PREREQ 'setup fake editor' '\n \t(echo \"#!$SHELL_PATH\" &&\n \t echo \"echo fake edit >>\\\"\\$1\\\"\"\n-- \n1.7.2.3\n"},{"id":"153805","messageId":"7v4oci11k6.fsf@alter.siamese.dyndns.org","threadId":"25443","inReplyTo":"1287481964-8883-1-git-send-email-ospite@studenti.unina.it","subject":"Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-19T18:26:33Z","receivedAt":"2010-10-19T18:26:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antonio Ospite writes:\n\n> Make second and subsequent patches appear as replies to the first patch,\n> even when an initial In-Reply-To is supplied; this is the typical\n> behaviour we want when we send a series with cover letter in reply to\n> some discussion, and this is also what the man page says about\n> the --in-reply-to option.\n\nI am not so sure if that is what the documentation says.\n\n 1. When --in-reply-to gives $reply_to, the first one becomes a reply to\n that message, with or without --chain-reply-to.\n\n 2. When --chain-reply-to is in effect, all the messages are strung\n together to form a single chain. The first message may be in reply to\n the $reply_to given by --in-reply-to command line option (see\n previous), or the root of the discussion thread. The second one is a\n response to the first one, and the third one is a response to the\n second one, etc.\n\n 3. When --chain-reply-to is not in effect:\n\n a. When --in-reply-to is used, too, the second and the subsequent ones\n become replies to $reply_to. Together with the first rule, all\n messages become replies to $reply_to given by --in-reply-to.\n\n b. When --in-reply-to is not used, presumably the second and\n subsequent ones become replies to the first one, which would be the\n root.\n\nThe documentation is reasonably clear about the 1., 2. and 3a. above, I\nthink, even though I do not think 3b. is clearly specified.\n\nIf you are changing 3a. above so that the first message becomes a response\nto $reply_to, and the second one becomes a response to the first message\n(and the third and subsequent ones too when --chain-reply-to is not in\neffect), you would need to update the documentation as well. Even if it\nmight be of good kind, it would be a change of the established behaviour.\n\n> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\n> index a298eb0..410b85f 100755\n> --- a/t/t9001-send-email.sh\n> +++ b/t/t9001-send-email.sh\n> @@ -295,6 +295,20 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '\n> \t! grep \"^In-Reply-To: < *>\" msgtxt1\n> '\n> \n> +test_expect_success $PREREQ 'In-Reply-To in second patch with --thread' '\n> +\tclean_fake_sendmail &&\n> +\tgit send-email \\\n> +\t\t--from=\"Example \" \\\n> +\t\t--to=nobody@example.com \\\n> +\t\t--thread \\\n> +\t\t--in-reply-to=\"\" \\\n> +\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n> +\t\t$patches $patches \\\n> +\t\t2>errors\n\nYou are breaking the && chain here.\n\n> + # The second patch should be seen as reply to the first one\n> + test $(sed -n -e \"s/^In-Reply-To:\\(.*\\)/\\1/p\" msgtxt2) = $(sed -n -e \"s/^Message-Id:\\(.*\\)/\\1/p\" msgtxt1)\n> +'\n\nYou would need to test the interaction with --chain-reply-to as well, so\nthere should be another test, and you would probably need three messages\nfed to send-email not just two to see the effect of the interaction.\n\nThanks.\n"},{"id":"153810","messageId":"7vzkuayqbf.fsf@alter.siamese.dyndns.org","threadId":"25443","inReplyTo":"7v4oci11k6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-19T18:45:24Z","receivedAt":"2010-10-19T18:45:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> +\t\t$patches $patches \\\n>> +\t\t2>errors\n>\n> You are breaking the && chain here.\n>\n>> + # The second patch should be seen as reply to the first one\n>> + test $(sed -n -e \"s/^In-Reply-To:\\(.*\\)/\\1/p\" msgtxt2) = $(sed -n -e \"s/^Message-Id:\\(.*\\)/\\1/p\" msgtxt1)\n>> +'\n>\n> You would need to test the interaction with --chain-reply-to as well, so\n> there should be another test, and you would probably need three messages\n> fed to send-email not just two to see the effect of the interaction.\n\nIOW, the test part of the patch should look something like this.\n\nNote that the below uses the current semantics (3a. in the previous\nmessage), not your version of the definition.\n\nI would suggest using this one as the first patch in your series, perhaps\nwith a documentation update to clarify the semantics of 3b. in my previous\nmessage. Then change git-send-email and update the test, as your change\nwill break the expected behaviour of the first test added here, and\ndocument the change of semantics 3a. in the second patch in your series.\n\n t/t9001-send-email.sh | 41 +++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 41 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 07c50c7..c7e5c93 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -295,6 +295,47 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '\n \t! grep \"^In-Reply-To: < *>\" msgtxt1\n '\n \n+test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '\n+\tclean_fake_sendmail &&\n+\techo \"\" >expect &&\n+\tgit send-email \\\n+\t\t--from=\"Example \" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--no-chain-reply-to \\\n+\t\t--in-reply-to=\"$(cat expect)\" \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t$patches $patches $patches \\\n+\t\t2>errors &&\n+\t# All the messages are replies to --in-reply-to\n+\tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt1 >actual &&\n+\ttest_cmp expect actual &&\n+\tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt2 >actual &&\n+\ttest_cmp expect actual &&\n+\tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt3 >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success $PREREQ 'In-Reply-To with --chain-reply-to' '\n+\tclean_fake_sendmail &&\n+\techo \"\" >expect &&\n+\tgit send-email \\\n+\t\t--from=\"Example \" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--chain-reply-to \\\n+\t\t--in-reply-to=\"$(cat expect)\" \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t$patches $patches $patches \\\n+\t\t2>errors &&\n+\tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt1 >actual &&\n+\ttest_cmp expect actual &&\n+\tsed -n -e \"s/^Message-Id: *\\(.*\\)/\\1/p\" msgtxt1 >expect &&\n+\tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt2 >actual &&\n+\ttest_cmp expect actual &&\n+\tsed -n -e \"s/^Message-Id: *\\(.*\\)/\\1/p\" msgtxt2 >expect &&\n+\tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt3 >actual &&\n+\ttest_cmp expect actual\n+'\n+\n test_expect_success $PREREQ 'setup fake editor' '\n \t(echo \"#!$SHELL_PATH\" &&\n \t echo \"echo fake edit >>\\\"\\$1\\\"\"\n"},{"id":"153834","messageId":"20101020004533.b64d446c.ospite@studenti.unina.it","threadId":"25443","inReplyTo":"7v4oci11k6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-10-19T22:45:33Z","receivedAt":"2010-10-19T22:45:33Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"On Tue, 19 Oct 2010 11:26:33 -0700\nJunio C Hamano wrote:\n\nThanks for commenting Junio.\n\n> Antonio Ospite writes:\n> \n> > Make second and subsequent patches appear as replies to the first patch,\n> > even when an initial In-Reply-To is supplied; this is the typical\n> > behaviour we want when we send a series with cover letter in reply to\n> > some discussion, and this is also what the man page says about\n> > the --in-reply-to option.\n> \n> I am not so sure if that is what the documentation says.\n>\n\nSorry, I meant the man page part about --[no-]chain-reply-to, I mistyped\nthat and generated more confusion than was \"necessary\".\n\n> 1. When --in-reply-to gives $reply_to, the first one becomes a reply to\n> that message, with or without --chain-reply-to.\n>\n\nNo doubts on that.\n\n> 2. When --chain-reply-to is in effect, all the messages are strung\n> together to form a single chain. The first message may be in reply to\n> the $reply_to given by --in-reply-to command line option (see\n> previous), or the root of the discussion thread. The second one is a\n> response to the first one, and the third one is a response to the\n> second one, etc.\n>\n\nThis is pretty clear as well.\n\n> 3. When --chain-reply-to is not in effect:\n>\n> a. When --in-reply-to is used, too, the second and the subsequent ones\n> become replies to $reply_to. Together with the first rule, all\n> messages become replies to $reply_to given by --in-reply-to.\n> \n> b. When --in-reply-to is not used, presumably the second and\n> subsequent ones become replies to the first one, which would be the\n> root.\n> \n> The documentation is reasonably clear about the 1., 2. and 3a. above, I\n> think, even though I do not think 3b. is clearly specified.\n>\n\nIn general, 3b. is specified in --[no-]chain-reply-to section, the\n\"problem\" with 3a. is that --in-reply-to _overrides_ the behavior\nspecified by --no-chain-reply-to.\n\nSo I think that the whole issue really boils down to the question:\nShould --in-reply-to apply _only_ to the first email?\nThe doc for the corresponding git-format-patch option gives _one_\nanswer, and you know that :)\n\nBy answering to this question with a YES also in git-send-email, we are\nmaking --in-reply-to *independent* from --[no-]chain-reply-to, hence\nthe very simple test.\n\n> If you are changing 3a. above so that the first message becomes a response\n> to $reply_to, and the second one becomes a response to the first message\n> (and the third and subsequent ones too when --chain-reply-to is not in\n> effect), you would need to update the documentation as well. Even if it\n> might be of good kind, it would be a change of the established behaviour.\n>\n\nRight, the documentation needs be updated as well, thanks for pointing\nthis out. I think I am going to copy from the git-format-patch man\npage.\nSo, do you agree to this change of behavior as long as it is documented?\n\n> > diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\n> > index a298eb0..410b85f 100755\n> > --- a/t/t9001-send-email.sh\n> > +++ b/t/t9001-send-email.sh\n> > @@ -295,6 +295,20 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '\n> > \t! grep \"^In-Reply-To: < *>\" msgtxt1\n> > '\n> > \n> > +test_expect_success $PREREQ 'In-Reply-To in second patch with --thread' '\n> > +\tclean_fake_sendmail &&\n> > +\tgit send-email \\\n> > +\t\t--from=\"Example \" \\\n> > +\t\t--to=nobody@example.com \\\n> > +\t\t--thread \\\n> > +\t\t--in-reply-to=\"\" \\\n> > +\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n> > +\t\t$patches $patches \\\n> > +\t\t2>errors\n> \n> You are breaking the && chain here.\n>\n\nSome other tests do that as well, the last line is a command by\nitself not and-chained with the git-send-email invocation. I guess the\nlogic behind this is that the test succeeds if the _last_ command\nsucceeds. If this is wrong then some other tests are affected too.\n\n> > + # The second patch should be seen as reply to the first one\n> > + test $(sed -n -e \"s/^In-Reply-To:\\(.*\\)/\\1/p\" msgtxt2) = $(sed -n -e \"s/^Message-Id:\\(.*\\)/\\1/p\" msgtxt1)\n> > +'\n> \n> You would need to test the interaction with --chain-reply-to as well, so\n> there should be another test, and you would probably need three messages\n> fed to send-email not just two to see the effect of the interaction.\n> \n\nI saw the tests in the other mail, but under my interpretation\nwe should just ensure --in-reply-to is applying to the first\nmessage only (so we check the second one), if so from the third one on\n--[no-]chain-reply-to is totally unrelated to --in-reply-to.\n\nI think I can make the test more explicit tho, like:\n(\"In-Reply-To\" of second message) != $initial_reply_to\n\nThanks,\n Antonio\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"},{"id":"154446","messageId":"20101026155043.f7e24764.ospite@studenti.unina.it","threadId":"25443","inReplyTo":"20101020004533.b64d446c.ospite@studenti.unina.it","subject":"Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-10-26T13:50:43Z","receivedAt":"2010-10-26T13:50:43Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"On Wed, 20 Oct 2010 00:45:33 +0200\nAntonio Ospite wrote:\n\n> On Tue, 19 Oct 2010 11:26:33 -0700\n> Junio C Hamano wrote:\n> \n> Thanks for commenting Junio.\n>\n\nJunio, did you see the comments inlined in the previous message? Maybe\nthe \"Thanks\" line above made you think that there were no more comments?\n\nIf you saw them and agree with what I wrote then I am sending a v3 in\nsome days adding just the doc updates.\n\nThanks,\n Antonio\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"},{"id":"155267","messageId":"1288990769-13307-1-git-send-email-ospite@studenti.unina.it","threadId":"25443","inReplyTo":"20101020004533.b64d446c.ospite@studenti.unina.it","subject":"[PATCH v3] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-11-05T20:59:29Z","receivedAt":"2010-11-05T20:59:29Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"When an initial In-Reply-To is supplied it should apply only to the\nfirst email, second and subsequent messages should behave just according\nto the --[no-]chain-reply-to setting; this is the typical behaviour we\nwant when we send a series with cover letter in reply to some\ndiscussion, this is what the man page says about the\n--[no-]chain-reply-to option and this is also how the --in-reply-to\noption behaves in git-format-patch.\n\nMoreover, when $initial_reply_to is asked to the user interactively it\nis asked as the \"Message-ID to be used as In-Reply-To for the _first_\nemail\", this makes the user think that the second and subsequent patches\nare not using it but are considered as replies to the first message or\nchained according to the --[no-]chain-reply setting.\n\nAdjust also the documentation about --in-reply-to to avoid ambiguities.\n\nNOTE: This patch changes the current behaviour and brings it to be what\nI think was the intentions stated in the documentation, also aligning it\nto how git-format-patch behaves; in order to achieve the old behaviour\nof a flat structure in reply to something the user can always use\n\"--no-thread --in-reply-to <...>\".\n\nSigned-off-by: Antonio Ospite \n---\n\nChanges since v2:\n - Make the purpose of the patch more explicit\n - Adjust the documentation\n - Make the test narrower and more explicit as well\n\nI am CCing some of the latest contributors to git-send-email.perl\n\nJuno, there are still some unanswered questions (one about the\nand-chains in tests) in one of previous mails in this thread.\n\nWith Best Regards,\n Antonio\n\n Documentation/git-send-email.txt | 8 +++++---\n git-send-email.perl | 3 ++-\n t/t9001-send-email.sh | 14 ++++++++++++++\n 3 files changed, 21 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 05904e0..acbff9b 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -82,9 +82,11 @@ See the CONFIGURATION section for 'sendemail.multiedit'.\n \tset, as returned by \"git var -l\".\n \n --in-reply-to=::\n-\tSpecify the contents of the first In-Reply-To header.\n-\tSubsequent emails will refer to the previous email\n-\tinstead of this if --chain-reply-to is set.\n+\tMake the first mail (or all the mails with `--no-thread`) appear as a\n+\treply to the given Message-Id, which avoids breaking threads to\n+\tprovide a new patch series.\n+\tThe second and subsequent emails will be sent as replies according to\n+\tthe --[no]-chain-reply-to setting.\n \tOnly necessary if --compose is also set. If --compose\n \tis not set, this will be prompted for.\n \ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex f68ed5a..fe6b848 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1319,7 +1319,8 @@ foreach my $t (@files) {\n \n \t# set up for the next message\n \tif ($thread && $message_was_sent &&\n-\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n+\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0 ||\n+\t\t$message_num == 1)) {\n \t\t$reply_to = $message_id;\n \t\tif (length $references > 0) {\n \t\t\t$references .= \"\\n $message_id\";\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex d1ba252..c85be0f 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -313,6 +313,20 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '\n \t! grep \"^In-Reply-To: < *>\" msgtxt1\n '\n \n+test_expect_success $PREREQ 'Apply initial In-Reply-To only to first patch with --thread' '\n+\tclean_fake_sendmail &&\n+\tgit send-email \\\n+\t\t--from=\"Example \" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--thread \\\n+\t\t--in-reply-to=\"\" \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t$patches $patches \\\n+\t\t2>errors\n+ # The second message should not have the initial In-Reply-To\n+ test $(sed -n -e \"s/^In-Reply-To: \\(.*\\)/\\1/p\" msgtxt2) != \"\"\n+'\n+\n test_expect_success $PREREQ 'setup fake editor' '\n \t(echo \"#!$SHELL_PATH\" &&\n \t echo \"echo fake edit >>\\\"\\$1\\\"\"\n-- \n1.7.2.3\n"},{"id":"155268","messageId":"20101105214159.GA4457@burratino","threadId":"25443","inReplyTo":"20101020004533.b64d446c.ospite@studenti.unina.it","subject":"Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-05T21:41:59Z","receivedAt":"2010-11-05T21:41:59Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Antonio,\n\nAntonio Ospite wrote:\n> Junio C Hamano wrote:\n\n>> You are breaking the && chain here.\n>\n> Some other tests do that as well, the last line is a command by\n> itself not and-chained with the git-send-email invocation. I guess the\n> logic behind this is that the test succeeds if the _last_ command\n> succeeds. If this is wrong then some other tests are affected too.\n\nYes, breaking the && chain is never a good thing.\n\nSee:\n\n - t/README: \"Chain your test assertions\"\n - v1.5.4~20 (t9001: add missing && operators, 2008-01-21)\n - git log --grep=&&\n\nHope that helps,\nJonathan\n"},{"id":"155273","messageId":"vpqtyjvo0tp.fsf@bauges.imag.fr","threadId":"25443","inReplyTo":"1288990769-13307-1-git-send-email-ospite@studenti.unina.it","subject":"Re: [PATCH v3] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-11-05T22:36:02Z","receivedAt":"2010-11-05T22:36:02Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Antonio Ospite writes:\n\n> When an initial In-Reply-To is supplied it should apply only to the\n> first email, second and subsequent messages should behave just according\n> to the --[no-]chain-reply-to setting; this is the typical behaviour we\n> want when we send a series with cover letter in reply to some\n> discussion,\n\n+1 on this. I've been biten by this behavior sending the v2 of\na patch serie --in-reply-to the cover letter for the v1. The two\nversions of each patch appear as reply to the original cover letter,\nit's kind of a mess. I was really expecting the patch serie to appear\nas a separate subtree in the discussion.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"155369","messageId":"20101108120308.df67214e.ospite@studenti.unina.it","threadId":"25443","inReplyTo":"20101105214159.GA4457@burratino","subject":"Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-11-08T11:03:08Z","receivedAt":"2010-11-08T11:03:08Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"On Fri, 5 Nov 2010 16:41:59 -0500\nJonathan Nieder wrote:\n\n> Hi Antonio,\n> \n> Antonio Ospite wrote:\n> > Junio C Hamano wrote:\n> \n> >> You are breaking the && chain here.\n> >\n> > Some other tests do that as well, the last line is a command by\n> > itself not and-chained with the git-send-email invocation. I guess the\n> > logic behind this is that the test succeeds if the _last_ command\n> > succeeds. If this is wrong then some other tests are affected too.\n> \n> Yes, breaking the && chain is never a good thing.\n> \n> See:\n> \n> - t/README: \"Chain your test assertions\"\n> - v1.5.4~20 (t9001: add missing && operators, 2008-01-21)\n> - git log --grep=&&\n> \n\nThanks Jonathan, I am fixing that also to some other tests in t9001\nright now.\n\nLet me know if the v3 in this series is going to be applied as is, so I\ncan fix the newly added test too. If a v4 is needed than I'll fix my\ntest there.\n\nI would also like to point your attention on tests like\n\"confirm by default (due to cc)\" and following in t9001, which are\nstoring return value of an intermediate command, how to fix those?\n\nThanks,\n Antonio\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"},{"id":"155514","messageId":"7vy692kx8k.fsf@alter.siamese.dyndns.org","threadId":"25443","inReplyTo":"vpqtyjvo0tp.fsf@bauges.imag.fr","subject":"Re: [PATCH v3] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-09T21:23:07Z","receivedAt":"2010-11-09T21:23:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> I've been biten by this behavior sending the v2 of\n> a patch serie --in-reply-to the cover letter for the v1. The two\n> versions of each patch appear as reply to the original cover letter,\n> it's kind of a mess. I was really expecting the patch serie to appear\n> as a separate subtree in the discussion.\n\nThe above is much better description of what issue the patch is trying to\naddress; something like that should go to the description.\n\nAntonio, I've already queued a few tests that document the established\nbehaviour on ao/send-email-irt branch (54aae5e1), so could you rebase your\npatch on it, perhaps with an updated explanation in the log (and in the\ndocumentation)?\n\nThanks, both.\n"},{"id":"155588","messageId":"20101110124522.0dff4076.ospite@studenti.unina.it","threadId":"25443","inReplyTo":"7vy692kx8k.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-11-10T11:45:22Z","receivedAt":"2010-11-10T11:45:22Z","isPatch":true,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"On Tue, 09 Nov 2010 13:23:07 -0800\nJunio C Hamano wrote:\n\n> Matthieu Moy writes:\n> \n> > I've been biten by this behavior sending the v2 of\n> > a patch serie --in-reply-to the cover letter for the v1. The two\n> > versions of each patch appear as reply to the original cover letter,\n> > it's kind of a mess. I was really expecting the patch serie to appear\n> > as a separate subtree in the discussion.\n> \n> The above is much better description of what issue the patch is trying to\n> address; something like that should go to the description.\n>\n\nAlright, I'll try mentioning the actual use case too.\n\n> Antonio, I've already queued a few tests that document the established\n> behaviour on ao/send-email-irt branch (54aae5e1), so could you rebase your\n> patch on it, perhaps with an updated explanation in the log (and in the\n> documentation)?\n>\n\nJunio, ao/send-email-irt seems to have been merged into origin/next, so\nI am rebasing on that. About the tests, I am going to modify one of your\ntests instead of adding another one, is that OK? This is a change of the\nestablished behavior after all, so the relative test have to change too,\nsomething along these lines:\n\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 66e4852..c56787f 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -324,9 +324,11 @@ test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '\n --smtp-server=\"$(pwd)/fake.sendmail\" \\\n $patches $patches $patches \\\n 2>errors &&\n- # All the messages are replies to --in-reply-to\n+ # The first message is a reply to --in-reply-to\n sed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt1 >actual &&\n test_cmp expect actual &&\n+ # Second and subsequent messages are replies to the first one\n+ sed -n -e \"s/^Message-Id: *\\(.*\\)/\\1/p\" msgtxt1 >expect &&\n sed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt2 >actual &&\n test_cmp expect actual &&\n sed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt3 >actual &&\n\n\nLet me just stress out that 3a. as in 54aae5e1 is not well specified\neither, that's what all this fuss is about. I notice you didn't comment\nabout my view of the \"independence\" of the --in-reply-to setting wrt.\n--[no-]chain-reply-to but I guess that falls into the implicit/explicit\ndebate, so I am not pushing it and just follow your directions about\nexplicitly relating the two.\n\n> Thanks, both.\n> \n\nRegards,\n Antonio\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"},{"id":"155616","messageId":"7v62w5hsd4.fsf@alter.siamese.dyndns.org","threadId":"25443","inReplyTo":"20101110124522.0dff4076.ospite@studenti.unina.it","subject":"Re: [PATCH v3] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-10T19:48:55Z","receivedAt":"2010-11-10T19:48:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antonio Ospite writes:\n\n> ... About the tests, I am going to modify one of your\n> tests instead of adding another one, is that OK?\n\nIt is not just Ok but is preferred; that is a good way to document where\nthe behaviour changed how, and for what reason ;-).\n\nPerhaps an illustration in the documentation may help. Until I read what\nMatthieu wrote in his message, I didn't quite get why anybody wanted this\nnew behaviour---my understanding of which is to get something like this:\n\n [PATCH 0/2] Here is what I did...\n [PATCH 1/2] Clean up and tests\n [PATCH 2/2] Implementation\n [PATCH v2 0/3] Here is a reroll\n [PATCH v2 1/3] Clean up\n [PATCH v2 2/3] New tests\n [PATCH v2 3/3] Implementation\n\nwhen sending the re-rolled series, with the --in-reply-to for [v2 0/3] set\nto [0/2] of the original. If you illustrate the current behaviour in a\nsimilar way in your commit log message, perhaps side-by-side to save\nvertical space, it would help make it clear why people would want the new\nbehaviour.\n"},{"id":"155782","messageId":"1289573708-18573-1-git-send-email-ospite@studenti.unina.it","threadId":"25443","inReplyTo":"7v62w5hsd4.fsf@alter.siamese.dyndns.org","subject":"[PATCHi v4] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-11-12T14:55:08Z","receivedAt":"2010-11-12T14:55:08Z","isPatch":false,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"When an initial In-Reply-To is supplied it should apply only to the\nfirst email, second and subsequent messages should behave just according\nto the --[no-]chain-reply-to setting; this is also what the man page\nsays about the --[no-]chain-reply-to option and this is also how the\ncorrespondent git-format-patch option behaves.\n\nThis is the typical behaviour we |\nwant when we send a series with | [PATCH 0/2] Here is what I did...\ncover letter in reply to some | [PATCH 1/2] Clean up and tests\ndiscussion, the new patch series | [PATCH 2/2] Implementation\nshould appear as a separate subtree | [PATCH v2 0/3] Here is a reroll\nin the discussion, look at the v2 | [PATCH v2 1/3] Clean up\nseries in the illustration on the | [PATCH v2 2/3] New tests\nright to see what the new behaviour | [PATCH v2 3/3] Implementation\nensures. |\n\nMoreover, when $initial_reply_to is asked to the user interactively it\nis asked as the \"Message-ID to be used as In-Reply-To for the _first_\nemail\", this makes the user think that the second and subsequent patches\nare not using it but are considered as replies to the first message or\nchained according to the --[no-]chain-reply setting.\n\nFix also the documentation about --in-reply-to to avoid ambiguities.\n\nNOTE: This patch changes the current behaviour and brings it to be what\nI think were the intentions stated in the documentation, also aligning it\nto how git-format-patch behaves; in order to achieve the old behaviour\nof a flat structure in reply to something the user can always use\n\"--no-thread --in-reply-to <...>\".\n\nSigned-off-by: Antonio Ospite \n---\n\nHoping we are there. Patch is on top of origin/next.\n\nChanges since v3:\n - Change the test about 'In-Reply-To without --chain-reply-to' instead of\n providing a new one.\n - Illustrate an actual use case when describing the new behaviour, both in\n the commit message and in the documentation.\n\nIt is cool to see how such a small change in the code requires quite some\n\"communication overhead\", not a big surprise in general but in this case I\nwonder if I've been overly verbose.\n\nJunio, if you feel that the documentation and the commit message can be slimmed\ndown feel free to do it when committing the patch.\n\nMatthieu, maybe we can have a Tested-by: you, can't we?\n\nThanks a lot,\n Antonio\n\n Documentation/git-send-email.txt | 25 ++++++++++++++++++++-----\n git-send-email.perl | 3 ++-\n t/t9001-send-email.sh | 4 +++-\n 3 files changed, 25 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 05904e0..ebc024a 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -82,11 +82,26 @@ See the CONFIGURATION section for 'sendemail.multiedit'.\n \tset, as returned by \"git var -l\".\n \n --in-reply-to=::\n-\tSpecify the contents of the first In-Reply-To header.\n-\tSubsequent emails will refer to the previous email\n-\tinstead of this if --chain-reply-to is set.\n-\tOnly necessary if --compose is also set. If --compose\n-\tis not set, this will be prompted for.\n+\tMake the first mail (or all the mails with `--no-thread`) appear as a\n+\treply to the given Message-Id, which avoids breaking threads to\n+\tprovide a new patch series.\n+\tThe second and subsequent emails will be sent as replies according to\n+\tthe `--[no]-chain-reply-to` setting.\n++\n+So for example when `--thread` and `--no-chain-reply-to` are specified, the\n+second and subsequent patches will be replies to the first one like in the\n+illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:\n++\n+ [PATCH 0/2] Here is what I did...\n+ [PATCH 1/2] Clean up and tests\n+ [PATCH 2/2] Implementation\n+ [PATCH v2 0/3] Here is a reroll\n+ [PATCH v2 1/3] Clean up\n+ [PATCH v2 2/3] New tests\n+ [PATCH v2 3/3] Implementation\n++\n+Only necessary if --compose is also set. If --compose\n+is not set, this will be prompted for.\n \n --subject=::\n \tSpecify the initial subject of the email thread.\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex f68ed5a..fe6b848 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1319,7 +1319,8 @@ foreach my $t (@files) {\n \n \t# set up for the next message\n \tif ($thread && $message_was_sent &&\n-\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0)) {\n+\t\t(chain_reply_to() || !defined $reply_to || length($reply_to) == 0 ||\n+\t\t$message_num == 1)) {\n \t\t$reply_to = $message_id;\n \t\tif (length $references > 0) {\n \t\t\t$references .= \"\\n $message_id\";\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex 26c2e93..5e48318 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -324,9 +324,11 @@ test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '\n \t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n \t\t$patches $patches $patches \\\n \t\t2>errors &&\n-\t# All the messages are replies to --in-reply-to\n+\t# The first message is a reply to --in-reply-to\n \tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt1 >actual &&\n \ttest_cmp expect actual &&\n+\t# Second and subsequent messages are replies to the first one\n+\tsed -n -e \"s/^Message-Id: *\\(.*\\)/\\1/p\" msgtxt1 >expect &&\n \tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt2 >actual &&\n \ttest_cmp expect actual &&\n \tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt3 >actual &&\n-- \n1.7.2.3\n"},{"id":"155798","messageId":"7veiaqfels.fsf@alter.siamese.dyndns.org","threadId":"25443","inReplyTo":"1289573708-18573-1-git-send-email-ospite@studenti.unina.it","subject":"Re: [PATCHi v4] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-12T20:53:35Z","receivedAt":"2010-11-12T20:53:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antonio Ospite writes:\n\n> When an initial In-Reply-To is supplied it should apply only to the\n> first email, second and subsequent messages should behave just according\n> to the --[no-]chain-reply-to setting; this is also what the man page\n> says about the --[no-]chain-reply-to option and this is also how the\n> correspondent git-format-patch option behaves.\n>\n> This is the typical behaviour we |\n> want when we send a series with | [PATCH 0/2] Here is what I did...\n> cover letter in reply to some | [PATCH 1/2] Clean up and tests\n> discussion, the new patch series | [PATCH 2/2] Implementation\n> should appear as a separate subtree | [PATCH v2 0/3] Here is a reroll\n> in the discussion, look at the v2 | [PATCH v2 1/3] Clean up\n> series in the illustration on the | [PATCH v2 2/3] New tests\n> right to see what the new behaviour | [PATCH v2 3/3] Implementation\n> ensures. |\n\nYuck.\n\nIt is a common trap to think that everybody already knows what you have\nbeen suffering from. It certainly is sufficient to show the output after\nyour patch to convince them that your change is a good thing.\n\nIOW, if you do two-column, please do it right ;-). The LHS should show\nhow the output _used to_ look like, so that even people who didn't\nparticulary care (because they never hit the issue) can see why the\nupdated behaviour is desirable.\n"},{"id":"155800","messageId":"7v1v6qfc9e.fsf@alter.siamese.dyndns.org","threadId":"25443","inReplyTo":"1289573708-18573-1-git-send-email-ospite@studenti.unina.it","subject":"Re: [PATCHi v4] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-12T21:44:13Z","receivedAt":"2010-11-12T21:44:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Antonio Ospite writes:\n\n> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\n> index 26c2e93..5e48318 100755\n> --- a/t/t9001-send-email.sh\n> +++ b/t/t9001-send-email.sh\n> @@ -324,9 +324,11 @@ test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '\n> \t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n> \t\t$patches $patches $patches \\\n> \t\t2>errors &&\n> -\t# All the messages are replies to --in-reply-to\n> +\t# The first message is a reply to --in-reply-to\n> \tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt1 >actual &&\n> \ttest_cmp expect actual &&\n> +\t# Second and subsequent messages are replies to the first one\n> +\tsed -n -e \"s/^Message-Id: *\\(.*\\)/\\1/p\" msgtxt1 >expect &&\n> \tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt2 >actual &&\n> \ttest_cmp expect actual &&\n> \tsed -n -e \"s/^In-Reply-To: *\\(.*\\)/\\1/p\" msgtxt3 >actual &&\n\nLooks good ;-)\n\nI'll do the obvious fix-up (below) at my end, so if there is nothing else\nthere is no need to resend.\n\n Look at the v2 series in the illustration to see what the new behavior\n ensures:\n\n (before the patch) | (after the patch)\n [PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did...\n [PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests\n [PATCH 2/2] Implementation | [PATCH 2/2] Implementation\n [PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll\n [PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up\n [PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests\n [PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation\n\n This is the typical behaviour we want when we send a series with cover\n letter in reply to some discussion, the new patch series should appear\n as a separate subtree in the discussion.\n\nThanks.\n"},{"id":"155803","messageId":"20101112235100.efad9631.ospite@studenti.unina.it","threadId":"25443","inReplyTo":"7v1v6qfc9e.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCHi v4] git-send-email.perl: make initial In-Reply-To apply only to first email","fromName":"Antonio Ospite","fromEmail":"ospite@studenti.unina.it","sentAt":"2010-11-12T22:51:00Z","receivedAt":"2010-11-12T22:51:00Z","isPatch":false,"sender":{"key":"ospite@studenti.unina.it","avatar":"https://gravatar.com/avatar/ea788baa2a3a207a84097c6f4f7b11d4201a80060933ef67584f648f17005552?d=mp&s=160"},"body":"On Fri, 12 Nov 2010 13:44:13 -0800\nJunio C Hamano wrote:\n\n> Antonio Ospite writes:\n> \n[...]\n> I'll do the obvious fix-up (below) at my end, so if there is nothing else\n> there is no need to resend.\n>\n> Look at the v2 series in the illustration to see what the new behavior\n> ensures:\n> \n> (before the patch) | (after the patch)\n> [PATCH 0/2] Here is what I did... | [PATCH 0/2] Here is what I did...\n> [PATCH 1/2] Clean up and tests | [PATCH 1/2] Clean up and tests\n> [PATCH 2/2] Implementation | [PATCH 2/2] Implementation\n> [PATCH v2 0/3] Here is a reroll | [PATCH v2 0/3] Here is a reroll\n> [PATCH v2 1/3] Clean up | [PATCH v2 1/3] Clean up\n> [PATCH v2 2/3] New tests | [PATCH v2 2/3] New tests\n> [PATCH v2 3/3] Implementation | [PATCH v2 3/3] Implementation\n> \n[...]\n\nThanks for taking care of that, I won't forget the lesson.\n\nRegards,\n Antonio\n\n-- \nAntonio Ospite\nhttp://ao2.it\n\nPGP public key ID: 0x4553B001\n\nA: Because it messes up the order in which people normally read text.\n See http://en.wikipedia.org/wiki/Posting_style\nQ: Why is top-posting such a bad thing?\n"}]}