{"thread":{"id":"63537","subject":"[PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited","startedAt":"2025-05-28T06:39:38Z","lastAt":"2025-05-29T03:26:42Z","messageCount":5,"participants":["Aditya Garg","Junio C Hamano"],"isPatch":true,"patchVersion":5,"patchTotal":2},"messages":[{"id":"519043","messageId":"5103ea4034cd4a8438865a2d3da19a92dda54013.1748414082.git.gargaditya08@live.com","threadId":"63537","inReplyTo":"cover.1748414082.git.gargaditya08@live.com","subject":"[PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-28T06:39:32Z","receivedAt":"2025-05-28T06:39:38Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"Whenever we send a thread of emails using send-email, a message number\nis internally assigned to each email. This number is used to track the\norder of the emails in the thread. Whenever a new message is processed\nin a thread, the current script logic increases the message number by\none, which is intended.\n\nBut, if a message is edited and then resent, its message number again\ngets increased. This is because the script uses the same logic to\nprocess the edited message, which it uses to send the next message.\n\nThis minor bug is usually harmless, unless some special situations arise.\nOne such situation is when the first message in a thread is edited\nand resent, and an `--in-reply-to` argument is also passed to send-email.\nIn this case, if the user has chosen shallow threading, the threading\ndoes not work as expected, and all messages become replies to the\nMessage-ID specified in the `--in-reply-to` argument.\n\nThe reason for this bug is hidden in the code for threading itself.\n\nif ($thread) {\n\tif ($message_was_sent &&\n\t ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 ||\n\t $message_num == 1)) {\n\t\t$in_reply_to = $message_id;\n\t\tif (length $references > 0) {\n\t\t\t$references .= \"\\n $message_id\";\n\t\t} else {\n\t\t\t$references = \"$message_id\";\n\t\t}\n\t}\n}\n\nHere `$message_num` is the current message number, and `$in_reply_to` is\nthe Message-ID of the message to which the current message is a reply.\nIn case `--in-reply-to` is specified, the `$in_reply_to` variable\nis set to the value of the `--in-reply-to` argument.\n\nWhenever this whole set of conditions is true, the script sets the\n`$in_reply_to` variable to the current message's ID. This is done to\nensure that the next message in the thread is a reply to this message.\n\nIn case we specify an `--in-reply-to` argument, and have shallow\nthreading, the only condition that can make this true is\n`$message_num == 1`, which is true for the first message in a thread.\nThus, the `$in_reply_to` variable gets set to the first message's ID.\nFor subsequent messages, the `$message_num` variable is always\ngreater than 1, and the whole set of conditions is false. Therefore, the\n`$in_reply_to` variable remains as the first message's ID. This is what\nwe expect in shallow threading. But if the user edits the first message\nand resends it, the `$message_num` variable gets increased by 1, and\nthus the condition `$message_num == 1` becomes false. This means that\nthe `$in_reply_to` variable is not set to the first message's ID. As a\nresult the next message in the thread is not a reply to the first\nmessage, but to the `--in-reply-to` argument, effectively breaking the\nthreading.\n\nIn case the user does not specify an `--in-reply-to` argument, the\n`!defined $in_reply_to` condition is true, and thus the `$in_reply_to`\nvariable is set to the first message's ID, and the threading works\nas expected, regardless of the message number.\n\nJust like the `$message_num` variable, the `$message_id_serial` variable\nalso increases by 1 whenever a new message is sent. This variable\ndisplays the message number in the Message-ID of the email.\n\nTo fix this bug, we need to ensure that the `$message_num` variable is\nnot increased by 1 when a message is edited and resent. We do this by\ndecreasing both the `$message_num` and `$message_id_serial` variables\nby 1 whenever the request to edit a message is received. This way, the\nnext message in the thread will have the same message number as the\nedited message. Therefore the threading will work as expected.\n\nThe same logic has also been applied in case the user drops a single\nmessage from the thread by choosing the \"[n]o\" option during\nconfirmation. By doing this, the next message in the thread is assigned\nthe message number of the dropped message, and thus the threading\nworks as expected.\n\nSigned-off-by: Aditya Garg \n---\n git-send-email.perl | 12 ++++++++++++\n 1 file changed, 12 insertions(+)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 55b7e00d29..b09251c4fc 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1639,8 +1639,20 @@ sub send_message {\n \t\t default => $ask_default);\n \t\tdie __(\"Send this email reply required\") unless defined $_;\n \t\tif (/^n/i) {\n+\t\t\t# If we are skipping a message, we should make sure that\n+\t\t\t# the next message is treated as the successor to the\n+\t\t\t# previously sent message, and not the skipped message.\n+\t\t\t$message_num--;\n+\t\t\t$message_id_serial--;\n \t\t\treturn 0;\n \t\t} elsif (/^e/i) {\n+\t\t\t# Since the same message will be sent again, we need to\n+\t\t\t# decrement the message number to the previous message.\n+\t\t\t# Otherwise, the edited message will be treated as a\n+\t\t\t# different message sent after the original non-edited\n+\t\t\t# message.\n+\t\t\t$message_num--;\n+\t\t\t$message_id_serial--;\n \t\t\treturn -1;\n \t\t} elsif (/^q/i) {\n \t\t\tcleanup_compose_files();\n-- \n2.43.0\n\n"},{"id":"519044","messageId":"cover.1748414082.git.gargaditya08@live.com","threadId":"63537","inReplyTo":"cover.1748274404.git.gargaditya08@live.com","subject":"[PATCH v5 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-28T06:39:31Z","receivedAt":"2025-05-28T06:39:40Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"Hi all,\n\nThis patch series fixes two minor issues with git-send-email.\n\nThe first patch fixes a bug that caused the message number to increase\nwhen a user edits an email. As a result of this bug, threads would\nbreak when a user edits an email.\n\nThe second patch improves the logging of the new message ID assigned by\nOutlook when a user edits an email.\n\nv2 - Change the bugfix logic used to fix the threading bug.\nv3 - Add additional patch to improve the logging of the new\n message ID assigned by Outlook.\nv4 - Completely rewrite the commit message of the first patch to\n explain the bug in detail and how it is fixed. Also, add\n example logs to explain the second patch.\nv5 - Fix numerous spelling and grammatical errors in the commit\n message of the first patch.\n\nAditya Garg (2):\n send-email: fix bug resulting in increased message number if a message\n is edited\n send-email: show the new message id assigned by outlook in the logs\n\n git-send-email.perl | 16 +++++++++++++++-\n 1 file changed, 15 insertions(+), 1 deletion(-)\n\nRange-diff:\n1: 63addf9d9b ! 1: 5103ea4034 send-email: fix bug resulting in increased message number if a message is edited\n @@ Commit message\n \n But, if a message is edited and then resent, its message number again\n gets increased. This is because the script uses the same logic to\n - process the edited message, which is uses the send the next message.\n + process the edited message, which it uses to send the next message.\n \n - This minor bug is usually harmless unless some special situations arise.\n + This minor bug is usually harmless, unless some special situations arise.\n One such situation is when the first message in a thread is edited\n and resent, and an `--in-reply-to` argument is also passed to send-email.\n - In this case if the user has chosen shallow threading, the threading\n - does not work as expected, and all messaged become as replies to the\n + In this case, if the user has chosen shallow threading, the threading\n + does not work as expected, and all messages become replies to the\n Message-ID specified in the `--in-reply-to` argument.\n \n The reason for this bug is hidden in the code for threading itself.\n @@ Commit message\n }\n }\n \n - Here $message_num is the current message number, and $in_reply_to is\n + Here `$message_num` is the current message number, and `$in_reply_to` is\n the Message-ID of the message to which the current message is a reply.\n In case `--in-reply-to` is specified, the `$in_reply_to` variable\n is set to the value of the `--in-reply-to` argument.\n @@ Commit message\n In case we specify an `--in-reply-to` argument, and have shallow\n threading, the only condition that can make this true is\n `$message_num == 1`, which is true for the first message in a thread.\n - Thus the $in_reply_to variable gets set to the first message's ID.\n + Thus, the `$in_reply_to` variable gets set to the first message's ID.\n For subsequent messages, the `$message_num` variable is always\n - greater than 1, and the whole set of conditions is false, and thus the\n - $in_reply_to variable remains as the first message's ID. This is what\n - we expect in shallow threading. But, in case the user edits the first\n - message and resends it, the `$message_num` variable gets increased by 1,\n - and thus the condition `$message_num == 1` becomes false. This means\n - that the `$in_reply_to` variable is not set to the first message's ID,\n - and thus the next message in the thread is not a reply to the first\n - message, but to the `--in-reply-to` argument, effectively breaking\n - the threading.\n + greater than 1, and the whole set of conditions is false. Therefore, the\n + `$in_reply_to` variable remains as the first message's ID. This is what\n + we expect in shallow threading. But if the user edits the first message\n + and resends it, the `$message_num` variable gets increased by 1, and\n + thus the condition `$message_num == 1` becomes false. This means that\n + the `$in_reply_to` variable is not set to the first message's ID. As a\n + result the next message in the thread is not a reply to the first\n + message, but to the `--in-reply-to` argument, effectively breaking the\n + threading.\n \n In case the user does not specify an `--in-reply-to` argument, the\n - !defined $in_reply_to condition is true, and thus the `$in_reply_to`\n + `!defined $in_reply_to` condition is true, and thus the `$in_reply_to`\n variable is set to the first message's ID, and the threading works\n - as expected, irrespective of what the message number is.\n + as expected, regardless of the message number.\n \n - Just like $message_num, $message_id_serial variable also increases by 1\n - whenever a new message is sent. This variable displays the message\n - number is the Message-ID of the email.\n + Just like the `$message_num` variable, the `$message_id_serial` variable\n + also increases by 1 whenever a new message is sent. This variable\n + displays the message number in the Message-ID of the email.\n \n - So, in order to fix this bug, we need to ensure that the $message_num\n - variable is not increased by 1 when a message is edited and resent.\n - We do this by decreasing the $message_num and $message_id_serial\n - variable by 1 whenever the request to edit a message is received. This\n - way, the next message in the thread will have the same message number as\n - the edited message, and thus the threading will work as expected.\n + To fix this bug, we need to ensure that the `$message_num` variable is\n + not increased by 1 when a message is edited and resent. We do this by\n + decreasing both the `$message_num` and `$message_id_serial` variables\n + by 1 whenever the request to edit a message is received. This way, the\n + next message in the thread will have the same message number as the\n + edited message. Therefore the threading will work as expected.\n \n The same logic has also been applied in case the user drops a single\n message from the thread by choosing the \"[n]o\" option during\n2: 72b3cd1bfb = 2: 6f2668de07 send-email: show the new message id assigned by outlook in the logs\n-- \n2.43.0\n\n"},{"id":"519045","messageId":"6f2668de07ecd1558888f382ef5ebc8b8bb10f51.1748414082.git.gargaditya08@live.com","threadId":"63537","inReplyTo":"cover.1748414082.git.gargaditya08@live.com","subject":"[PATCH v5 2/2] send-email: show the new message id assigned by outlook in the logs","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-28T06:39:34Z","receivedAt":"2025-05-28T06:39:45Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"Whenever an email is sent, send-email shows a log at last, which\ncontains all the headers of the email that were received by the\nreceipients.\n\nIn case outlook changes the Message-ID, a log for the same is shown to\nthe user, but that change is not reflected when the log containing all\nthe headers is displayed. Here is an example of the log that is shown\nwhen outlook changes the Message-ID:\n\nOutlook reassigned Message-ID to: \nOK. Log says:\nServer: smtp.office365.com\nMAIL FROM:\nRCPT TO:\nFrom: Aditya Garg \nTo: negahe7142@nomrista.com\nSubject: [PATCH] send-email: show the new message id assigned by outlook in the logs\nDate: Mon, 26 May 2025 20:28:36 +0530\nMessage-ID: <20250526145836.4825-1-gargaditya08@live.com>\nX-Mailer: git-send-email @GIT_VERSION@\nMIME-Version: 1.0\nContent-Transfer-Encoding: 8bit\n\nResult: 250\n\nThis patch fixes this by modifying the $header variable, which is\nresponsible for showing the logs at the end. Also, the log which states\nthat the Message-ID has been changed will now be shown only when\nsmtp-debug is enabled, since the main log having all of the headers is\nanyways displaying the new Message-ID. It should look like this after\nthis patch:\n\nOK. Log says:\nServer: smtp.office365.com\nMAIL FROM:\nRCPT TO:\nFrom: Aditya Garg \nTo: negahe7142@nomrista.com\nSubject: [PATCH] send-email: show the new message id assigned by outlook in the logs\nDate: Mon, 26 May 2025 20:29:22 +0530\nMessage-ID: \nX-Mailer: git-send-email @GIT_VERSION@\nMIME-Version: 1.0\nContent-Transfer-Encoding: 8bit\n\nResult: 250\n\nSigned-off-by: Aditya Garg \n---\n git-send-email.perl | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex b09251c4fc..e8019c40ba 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1776,7 +1776,9 @@ sub send_message {\n \t\tif (is_outlook($smtp_server)) {\n \t\t\tif ($smtp->message =~ /<([^>]+)>/) {\n \t\t\t\t$message_id = \"<$1>\";\n-\t\t\t\tprintf __(\"Outlook reassigned Message-ID to: %s\\n\"), $message_id;\n+\t\t\t\t# Replace the original Message-ID in $header with the new one\n+\t\t\t\t$header =~ s/^(Message-ID:\\s*).*\\n/${1}$message_id\\n/m;\n+\t\t\t\tprintf __(\"Outlook reassigned Message-ID to: %s\\n\"), $message_id if $smtp->debug;\n \t\t\t} else {\n \t\t\t\twarn __(\"Warning: Could not retrieve Message-ID from server response.\\n\");\n \t\t\t}\n-- \n2.43.0\n\n"},{"id":"519106","messageId":"xmqqcybspcvf.fsf@gitster.g","threadId":"63537","inReplyTo":"5103ea4034cd4a8438865a2d3da19a92dda54013.1748414082.git.gargaditya08@live.com","subject":"Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-28T22:52:04Z","receivedAt":"2025-05-28T22:52:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aditya Garg writes:\n\n> Subject: Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited\n\nIs this the same title Kristoffer said that it does not give much\nmeaningful information, to which you said you \"have re-written the\nwhole message\"?\n\ncf. \n\n> Whenever we send a thread of emails using send-email, a message number\n> is internally assigned to each email. This number is used to track the\n> order of the emails in the thread. Whenever a new message is processed\n> in a thread, the current script logic increases the message number by\n> one, which is intended.\n>\n> But, if a message is edited and then resent, its message number again\n> gets increased. This is because the script uses the same logic to\n> process the edited message, which it uses to send the next message.\n\n\"increase\" -> \"increment\" is more common to count up by one.\n\n> This minor bug is usually harmless, unless some special situations arise.\n> One such situation is when the first message in a thread is edited\n\nWhich makes it sound like you know of more than one bug but only\ntelling us about \"one such situation\" here. If so, what are others?\nIf not, the phrasing in this paragraph is somewhat misleading.\n\n> Here `$message_num` is the current message number, and `$in_reply_to` is\n> the Message-ID of the message to which the current message is a reply.\n> In case `--in-reply-to` is specified, the `$in_reply_to` variable\n> is set to the value of the `--in-reply-to` argument.\n>\n> Whenever this whole set of conditions is true, the script sets the\n> `$in_reply_to` variable to the current message's ID. This is done to\n> ensure that the next message in the thread is a reply to this message.\n\nOK.\n\n> To fix this bug, we need to ensure that the `$message_num` variable is\n> not increased by 1 when a message is edited and resent. We do this by\n> decreasing both the `$message_num` and `$message_id_serial` variables\n> by 1 whenever the request to edit a message is received. This way, the\n> next message in the thread will have the same message number as the\n> edited message. Therefore the threading will work as expected.\n\nHmph, isn't it more like \"after editing Nth message, we re-process\nthat edited message, and we used to call that edited message N+1th,\nwhich was wrong. We now keep the same numbering and call the edited\nmessage Nth (and the version before editing we didn't send, so there\nis no risk of sending two Nth messages)\"? \n\n> The same logic has also been applied in case the user drops a single\n> message from the thread by choosing the \"[n]o\" option during\n> confirmation. By doing this, the next message in the thread is assigned\n> the message number of the dropped message, and thus the threading\n> works as expected.\n\nOK.\n\nThe above explains why the patch needs to touch message_num. It\nwould be evfen better if it described what the variable is used for,\nexactly.\n\n Side note: during the initial round of this change, I explained\n that $num_sent is the counter in the batch we are sending out\n (hence it is reset to 0 when a batch fills and the next batch\n starts). If there is a similar concise and clear explanation of\n what $message_num? \"The number, counting from 1, of the message\n in the set of messages we are sending\", or something, perhaps?\n\nAnd none of the above justifies why this patch mucks with\nmessage_id_serial. Should it always be the same as message_num (in\nwhich case the natural question is \"why do we need both?\")?\n\nIf we can prove that message_num and message_id_serial must be\nincremented in sync, it is OK to have a separate topic that unifies\nthese two variables into just a single message_num, but I'd prefer\nnot to see message_id_serial mentioned above and touched below at\nall in this patch to fix the in_reply_to issue.\n\n> Signed-off-by: Aditya Garg \n> ---\n> git-send-email.perl | 12 ++++++++++++\n> 1 file changed, 12 insertions(+)\n>\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index 55b7e00d29..b09251c4fc 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -1639,8 +1639,20 @@ sub send_message {\n> \t\t default => $ask_default);\n> \t\tdie __(\"Send this email reply required\") unless defined $_;\n> \t\tif (/^n/i) {\n> +\t\t\t# If we are skipping a message, we should make sure that\n> +\t\t\t# the next message is treated as the successor to the\n> +\t\t\t# previously sent message, and not the skipped message.\n> +\t\t\t$message_num--;\n> +\t\t\t$message_id_serial--;\n> \t\t\treturn 0;\n> \t\t} elsif (/^e/i) {\n> +\t\t\t# Since the same message will be sent again, we need to\n> +\t\t\t# decrement the message number to the previous message.\n> +\t\t\t# Otherwise, the edited message will be treated as a\n> +\t\t\t# different message sent after the original non-edited\n> +\t\t\t# message.\n> +\t\t\t$message_num--;\n> +\t\t\t$message_id_serial--;\n> \t\t\treturn -1;\n> \t\t} elsif (/^q/i) {\n> \t\t\tcleanup_compose_files();\n"},{"id":"519132","messageId":"PN3PR01MB9597A24F38B01FE1F614D942B866A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM","threadId":"63537","inReplyTo":"xmqqcybspcvf.fsf@gitster.g","subject":"Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-29T03:26:36Z","receivedAt":"2025-05-29T03:26:42Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"\n\n> On 29 May 2025, at 4:22 AM, Junio C Hamano wrote:\n> \n> Aditya Garg writes:\n> \n>> Subject: Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited\n> \n> Is this the same title Kristoffer said that it does not give much\n> meaningful information, to which you said you \"have re-written the\n> whole message\"?\n\nI understood it as needing rewrite only of the body, and not the subject.\n> \n> cf. \n> \n>> Whenever we send a thread of emails using send-email, a message number\n>> is internally assigned to each email. This number is used to track the\n>> order of the emails in the thread. Whenever a new message is processed\n>> in a thread, the current script logic increases the message number by\n>> one, which is intended.\n>> \n>> But, if a message is edited and then resent, its message number again\n>> gets increased. This is because the script uses the same logic to\n>> process the edited message, which it uses to send the next message.\n> \n> \"increase\" -> \"increment\" is more common to count up by one.\nOk\n> \n>> This minor bug is usually harmless, unless some special situations arise.\n>> One such situation is when the first message in a thread is edited\n> \n> Which makes it sound like you know of more than one bug but only\n> telling us about \"one such situation\" here. If so, what are others?\n> If not, the phrasing in this paragraph is somewhat misleading.\n\nI'll change it.\n\n>> Here `$message_num` is the current message number, and `$in_reply_to` is\n>> the Message-ID of the message to which the current message is a reply.\n>> In case `--in-reply-to` is specified, the `$in_reply_to` variable\n>> is set to the value of the `--in-reply-to` argument.\n>> \n>> Whenever this whole set of conditions is true, the script sets the\n>> `$in_reply_to` variable to the current message's ID. This is done to\n>> ensure that the next message in the thread is a reply to this message.\n> \n> OK.\n> \n>> To fix this bug, we need to ensure that the `$message_num` variable is\n>> not increased by 1 when a message is edited and resent. We do this by\n>> decreasing both the `$message_num` and `$message_id_serial` variables\n>> by 1 whenever the request to edit a message is received. This way, the\n>> next message in the thread will have the same message number as the\n>> edited message. Therefore the threading will work as expected.\n> \n> Hmph, isn't it more like \"after editing Nth message, we re-process\n> that edited message, and we used to call that edited message N+1th,\n> which was wrong. We now keep the same numbering and call the edited\n> message Nth (and the version before editing we didn't send, so there\n> is no risk of sending two Nth messages)\"? \n\nYes\n\n> \n>> The same logic has also been applied in case the user drops a single\n>> message from the thread by choosing the \"[n]o\" option during\n>> confirmation. By doing this, the next message in the thread is assigned\n>> the message number of the dropped message, and thus the threading\n>> works as expected.\n> \n> OK.\n> \n> The above explains why the patch needs to touch message_num. It\n> would be evfen better if it described what the variable is used for,\n> exactly.\n\nWhenever we send a thread of emails using send-email, a message number\nis internally assigned to each email. This number is used to track the\norder of the emails in the thread.\n\nI had explained this in the starting.\n\n> \n> Side note: during the initial round of this change, I explained\n> that $num_sent is the counter in the batch we are sending out\n> (hence it is reset to 0 when a batch fills and the next batch\n> starts). If there is a similar concise and clear explanation of\n> what $message_num? \"The number, counting from 1, of the message\n> in the set of messages we are sending\", or something, perhaps?\n> \n> And none of the above justifies why this patch mucks with\n> message_id_serial. Should it always be the same as message_num (in\n> which case the natural question is \"why do we need both?\")?\n\nI had the similar question as well, but it also has special cases.\n\nIn case a person starts a thread using the --thread option of format-patch\nand by mistake deletes the message id header of a patch, the serial number\nstarts with one from that patch.\n\nAlthough honestly speaking, I myself am getting more confused as far as\nserial number is concerned, and I think its best to drop it since its not a\nbreaking change unlike message number. It's just to ensure a unique message\nID to all patches, and having incremented numbers is ok.\n\nMessage number definitely needs a fix since it breaks threads.\n\n> If we can prove that message_num and message_id_serial must be\n> incremented in sync, it is OK to have a separate topic that unifies\n> these two variables into just a single message_num, but I'd prefer\n> not to see message_id_serial mentioned above and touched below at\n> all in this patch to fix the in_reply_to issue.\n> \n>> Signed-off-by: Aditya Garg \n>> ---\n>> git-send-email.perl | 12 ++++++++++++\n>> 1 file changed, 12 insertions(+)\n>> \n>> diff --git a/git-send-email.perl b/git-send-email.perl\n>> index 55b7e00d29..b09251c4fc 100755\n>> --- a/git-send-email.perl\n>> +++ b/git-send-email.perl\n>> @@ -1639,8 +1639,20 @@ sub send_message {\n>> default => $ask_default);\n>> die __(\"Send this email reply required\") unless defined $_;\n>> if (/^n/i) {\n>> + # If we are skipping a message, we should make sure that\n>> + # the next message is treated as the successor to the\n>> + # previously sent message, and not the skipped message.\n>> + $message_num--;\n>> + $message_id_serial--;\n>> return 0;\n>> } elsif (/^e/i) {\n>> + # Since the same message will be sent again, we need to\n>> + # decrement the message number to the previous message.\n>> + # Otherwise, the edited message will be treated as a\n>> + # different message sent after the original non-edited\n>> + # message.\n>> + $message_num--;\n>> + $message_id_serial--;\n>> return -1;\n>> } elsif (/^q/i) {\n>> cleanup_compose_files();\n"}]}