# [PATCH v4 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix. 14 messages from 2025-05-26 to 2025-06-04. Participants: Aditya Garg, Junio C Hamano. Thread: https://gitlist.dev/t/63526 ## Aditya Garg, 2025-05-26 15:51 Subject: [PATCH v4 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix. Message-ID: URL: https://gitlist.dev/e/cover.1748274404.git.gargaditya08%40live.com ``` Hi all, This patch series fixes two minor issues with git-send-email. The first patch fixes a bug that caused the message number to increase when a user edits an email. As a result of this bug, threads would break when a user edits an email. The second patch improves the logging of the new message ID assigned by Outlook when a user edits an email. v2 - Change the bugfix logic used to fix the threading bug. v3 - Add additional patch to improve the logging of the new message ID assigned by Outlook. v4 - Completely rewrite the commit message of the first patch to explain the bug in detail and how it is fixed. Also, add example logs to explain the second patch. Aditya Garg (2): send-email: fix bug resulting in increased message number if a message is edited send-email: show the new message id assigned by outlook in the logs git-send-email.perl | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) Range-diff: 1: 259e20261e ! 1: 63addf9d9b send-email: fix bug resulting in increased message number if a message is edited @@ Metadata ## Commit message ## send-email: fix bug resulting in increased message number if a message is edited - In case a message is edited before it is sent, its message number gets - increased by 1, and so does its order in the message id. The cause of - this bug was that when a person attempts to edit the message, the whole - sub process_file gets terminated, and the user is asked to edit the message. - After necessary edits are done, the whole sub process_file is executed again. - The way sub process_file is designed, every time is runs, it increases the - $message_num variable by 1. The reason for this was that the function ran - again everytime a next message was sent in a thread, and thus we need to - increase the message number for that message. In case a user edits the message, - there is no check for the same and the new message gets treated as a subsequent - message of a thread, therefore increasing its message number by one. This - breaks the shallow thread logic which relies on $message_num being 1 for the - first message, and it gets changed in case the user edits the first message. - - So, upon scanning the whole code, there are two significant variables at play - here. First is $message_num, responsible for the message number and second - is $message_id_serial, responsible for showing the message number in the - Message-ID header. So, whenever we edit a message, lets just decrease them - by 1, so that when the whole process to compose and send the message starts, - these variables increase by 1 again, thus get set to the original values for - that message. - - We also are doing the same thing in case the user chooses to not send a message - out of many messages in a thread. By doing so, we will simply decrease these - variables by 1 for further messages, thus ensuring the whole thread doesn't - break. + Whenever we send a thread of emails using send-email, a message number + is internally assigned to each email. This number is used to track the + order of the emails in the thread. Whenever a new message is processed + in a thread, the current script logic increases the message number by + one, which is intended. + + But, if a message is edited and then resent, its message number again + gets increased. This is because the script uses the same logic to + process the edited message, which is uses the send the next message. + + This minor bug is usually harmless unless some special situations arise. + One such situation is when the first message in a thread is edited + and resent, and an `--in-reply-to` argument is also passed to send-email. + In this case if the user has chosen shallow threading, the threading + does not work as expected, and all messaged become as replies to the + Message-ID specified in the `--in-reply-to` argument. + + The reason for this bug is hidden in the code for threading itself. + + if ($thread) { + if ($message_was_sent && + ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 || + $message_num == 1)) { + $in_reply_to = $message_id; + if (length $references > 0) { + $references .= "\n $message_id"; + } else { + $references = "$message_id"; + } + } + } + + Here $message_num is the current message number, and $in_reply_to is + the Message-ID of the message to which the current message is a reply. + In case `--in-reply-to` is specified, the `$in_reply_to` variable + is set to the value of the `--in-reply-to` argument. + + Whenever this whole set of conditions is true, the script sets the + `$in_reply_to` variable to the current message's ID. This is done to + ensure that the next message in the thread is a reply to this message. + + In case we specify an `--in-reply-to` argument, and have shallow + threading, the only condition that can make this true is + `$message_num == 1`, which is true for the first message in a thread. + Thus the $in_reply_to variable gets set to the first message's ID. + For subsequent messages, the `$message_num` variable is always + greater than 1, and the whole set of conditions is false, and thus the + $in_reply_to variable remains as the first message's ID. This is what + we expect in shallow threading. But, in case the user edits the first + message and resends it, the `$message_num` variable gets increased by 1, + and thus the condition `$message_num == 1` becomes false. This means + that the `$in_reply_to` variable is not set to the first message's ID, + and thus the next message in the thread is not a reply to the first + message, but to the `--in-reply-to` argument, effectively breaking + the threading. + + In case the user does not specify an `--in-reply-to` argument, the + !defined $in_reply_to condition is true, and thus the `$in_reply_to` + variable is set to the first message's ID, and the threading works + as expected, irrespective of what the message number is. + + Just like $message_num, $message_id_serial variable also increases by 1 + whenever a new message is sent. This variable displays the message + number is the Message-ID of the email. + + So, in order to fix this bug, we need to ensure that the $message_num + variable is not increased by 1 when a message is edited and resent. + We do this by decreasing the $message_num and $message_id_serial + variable by 1 whenever the request to edit a message is received. This + way, the next message in the thread will have the same message number as + the edited message, and thus the threading will work as expected. + + The same logic has also been applied in case the user drops a single + message from the thread by choosing the "[n]o" option during + confirmation. By doing this, the next message in the thread is assigned + the message number of the dropped message, and thus the threading + works as expected. Signed-off-by: Aditya Garg 2: 65619ac4d7 ! 2: 72b3cd1bfb send-email: show the new message id assigned by outlook in the logs @@ Commit message send-email: show the new message id assigned by outlook in the logs Whenever an email is sent, send-email shows a log at last, which - contains all the headers of the email that was send successfully. - In case outlook changes the Message-ID, a log for the same is - shown to the user, but that change is not reflected when the log - containing all the headers is displayed. + contains all the headers of the email that were received by the + receipients. + + In case outlook changes the Message-ID, a log for the same is shown to + the user, but that change is not reflected when the log containing all + the headers is displayed. Here is an example of the log that is shown + when outlook changes the Message-ID: + + Outlook reassigned Message-ID to: + OK. Log says: + Server: smtp.office365.com + MAIL FROM: + RCPT TO: + From: Aditya Garg + To: negahe7142@nomrista.com + Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs + Date: Mon, 26 May 2025 20:28:36 +0530 + Message-ID: <20250526145836.4825-1-gargaditya08@live.com> + X-Mailer: git-send-email @GIT_VERSION@ + MIME-Version: 1.0 + Content-Transfer-Encoding: 8bit + + Result: 250 This patch fixes this by modifying the $header variable, which is - responsible for showing the logs at the end. Also, the log which - states that the Message-ID has been changed will now be shown only - when smtp-debug is enabled, since the main log having all of the - headers is anyways displaying the new Message-ID. + responsible for showing the logs at the end. Also, the log which states + that the Message-ID has been changed will now be shown only when + smtp-debug is enabled, since the main log having all of the headers is + anyways displaying the new Message-ID. It should look like this after + this patch: + + OK. Log says: + Server: smtp.office365.com + MAIL FROM: + RCPT TO: + From: Aditya Garg + To: negahe7142@nomrista.com + Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs + Date: Mon, 26 May 2025 20:29:22 +0530 + Message-ID: + X-Mailer: git-send-email @GIT_VERSION@ + MIME-Version: 1.0 + Content-Transfer-Encoding: 8bit + + Result: 250 Signed-off-by: Aditya Garg -- 2.43.0 ``` ## Aditya Garg, 2025-05-26 15:51 Subject: [PATCH v4 1/2] send-email: fix bug resulting in increased message number if a message is edited Message-ID: <63addf9d9b6491cba2148ba838f99119d50c0e68.1748274404.git.gargaditya08@live.com> URL: https://gitlist.dev/e/63addf9d9b6491cba2148ba838f99119d50c0e68.1748274404.git.gargaditya08%40live.com In-Reply-To: ``` Whenever we send a thread of emails using send-email, a message number is internally assigned to each email. This number is used to track the order of the emails in the thread. Whenever a new message is processed in a thread, the current script logic increases the message number by one, which is intended. But, if a message is edited and then resent, its message number again gets increased. This is because the script uses the same logic to process the edited message, which is uses the send the next message. This minor bug is usually harmless unless some special situations arise. One such situation is when the first message in a thread is edited and resent, and an `--in-reply-to` argument is also passed to send-email. In this case if the user has chosen shallow threading, the threading does not work as expected, and all messaged become as replies to the Message-ID specified in the `--in-reply-to` argument. The reason for this bug is hidden in the code for threading itself. if ($thread) { if ($message_was_sent && ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 || $message_num == 1)) { $in_reply_to = $message_id; if (length $references > 0) { $references .= "\n $message_id"; } else { $references = "$message_id"; } } } Here $message_num is the current message number, and $in_reply_to is the Message-ID of the message to which the current message is a reply. In case `--in-reply-to` is specified, the `$in_reply_to` variable is set to the value of the `--in-reply-to` argument. Whenever this whole set of conditions is true, the script sets the `$in_reply_to` variable to the current message's ID. This is done to ensure that the next message in the thread is a reply to this message. In case we specify an `--in-reply-to` argument, and have shallow threading, the only condition that can make this true is `$message_num == 1`, which is true for the first message in a thread. Thus the $in_reply_to variable gets set to the first message's ID. For subsequent messages, the `$message_num` variable is always greater than 1, and the whole set of conditions is false, and thus the $in_reply_to variable remains as the first message's ID. This is what we expect in shallow threading. But, in case the user edits the first message and resends it, the `$message_num` variable gets increased by 1, and thus the condition `$message_num == 1` becomes false. This means that the `$in_reply_to` variable is not set to the first message's ID, and thus the next message in the thread is not a reply to the first message, but to the `--in-reply-to` argument, effectively breaking the threading. In case the user does not specify an `--in-reply-to` argument, the !defined $in_reply_to condition is true, and thus the `$in_reply_to` variable is set to the first message's ID, and the threading works as expected, irrespective of what the message number is. Just like $message_num, $message_id_serial variable also increases by 1 whenever a new message is sent. This variable displays the message number is the Message-ID of the email. So, in order to fix this bug, we need to ensure that the $message_num variable is not increased by 1 when a message is edited and resent. We do this by decreasing the $message_num and $message_id_serial variable by 1 whenever the request to edit a message is received. This way, the next message in the thread will have the same message number as the edited message, and thus the threading will work as expected. The same logic has also been applied in case the user drops a single message from the thread by choosing the "[n]o" option during confirmation. By doing this, the next message in the thread is assigned the message number of the dropped message, and thus the threading works as expected. Signed-off-by: Aditya Garg --- git-send-email.perl | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/git-send-email.perl b/git-send-email.perl index 55b7e00d29..b09251c4fc 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1639,8 +1639,20 @@ sub send_message { default => $ask_default); die __("Send this email reply required") unless defined $_; if (/^n/i) { + # If we are skipping a message, we should make sure that + # the next message is treated as the successor to the + # previously sent message, and not the skipped message. + $message_num--; + $message_id_serial--; return 0; } elsif (/^e/i) { + # Since the same message will be sent again, we need to + # decrement the message number to the previous message. + # Otherwise, the edited message will be treated as a + # different message sent after the original non-edited + # message. + $message_num--; + $message_id_serial--; return -1; } elsif (/^q/i) { cleanup_compose_files(); -- 2.43.0 ``` ## Aditya Garg, 2025-05-26 15:51 Subject: [PATCH v4 2/2] send-email: show the new message id assigned by outlook in the logs Message-ID: <72b3cd1bfbce5ce6d82ea549445732b0caa02bbf.1748274404.git.gargaditya08@live.com> URL: https://gitlist.dev/e/72b3cd1bfbce5ce6d82ea549445732b0caa02bbf.1748274404.git.gargaditya08%40live.com In-Reply-To: ``` Whenever an email is sent, send-email shows a log at last, which contains all the headers of the email that were received by the receipients. In case outlook changes the Message-ID, a log for the same is shown to the user, but that change is not reflected when the log containing all the headers is displayed. Here is an example of the log that is shown when outlook changes the Message-ID: Outlook reassigned Message-ID to: OK. Log says: Server: smtp.office365.com MAIL FROM: RCPT TO: From: Aditya Garg To: negahe7142@nomrista.com Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs Date: Mon, 26 May 2025 20:28:36 +0530 Message-ID: <20250526145836.4825-1-gargaditya08@live.com> X-Mailer: git-send-email @GIT_VERSION@ MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Result: 250 This patch fixes this by modifying the $header variable, which is responsible for showing the logs at the end. Also, the log which states that the Message-ID has been changed will now be shown only when smtp-debug is enabled, since the main log having all of the headers is anyways displaying the new Message-ID. It should look like this after this patch: OK. Log says: Server: smtp.office365.com MAIL FROM: RCPT TO: From: Aditya Garg To: negahe7142@nomrista.com Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs Date: Mon, 26 May 2025 20:29:22 +0530 Message-ID: X-Mailer: git-send-email @GIT_VERSION@ MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Result: 250 Signed-off-by: Aditya Garg --- git-send-email.perl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl index b09251c4fc..e8019c40ba 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1776,7 +1776,9 @@ sub send_message { if (is_outlook($smtp_server)) { if ($smtp->message =~ /<([^>]+)>/) { $message_id = "<$1>"; - printf __("Outlook reassigned Message-ID to: %s\n"), $message_id; + # Replace the original Message-ID in $header with the new one + $header =~ s/^(Message-ID:\s*).*\n/${1}$message_id\n/m; + printf __("Outlook reassigned Message-ID to: %s\n"), $message_id if $smtp->debug; } else { warn __("Warning: Could not retrieve Message-ID from server response.\n"); } -- 2.43.0 ``` ## Aditya Garg, 2025-05-29 14:57 Subject: [PATCH v6 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix. Message-ID: URL: https://gitlist.dev/e/cover.1748529954.git.gargaditya08%40live.com In-Reply-To: ``` Hi all, This patch series fixes two minor issues with git-send-email. The first patch fixes a bug that caused the message number to increase when a user edits an email. As a result of this bug, threads would break when a user edits an email. The second patch improves the logging of the new message ID assigned by Outlook when a user edits an email. v2 - Change the bugfix logic used to fix the threading bug. v3 - Add additional patch to improve the logging of the new message ID assigned by Outlook. v4 - Completely rewrite the commit message of the first patch to explain the bug in detail and how it is fixed. Also, add example logs to explain the second patch. v5 - Fix numerous spelling and grammatical errors in the commit message of the first patch. v6 - Change the subject of the first patch. - Prefer using "increment" instead of "increase" in the commit message of the first patch. - Avoid decreasing the `$message_id_serial` variable in the first patch. Aditya Garg (2): send-email: fix bug resulting in broken threads if a message is edited send-email: show the new message id assigned by outlook in the logs git-send-email.perl | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) Range-diff against v5: 1: 5103ea4034 ! 1: d965439f76 send-email: fix bug resulting in increased message number if a message is edited @@ Metadata Author: Aditya Garg ## Commit message ## - send-email: fix bug resulting in increased message number if a message is edited + send-email: fix bug resulting in broken threads if a message is edited Whenever we send a thread of emails using send-email, a message number is internally assigned to each email. This number is used to track the order of the emails in the thread. Whenever a new message is processed - in a thread, the current script logic increases the message number by + in a thread, the current script logic increments the message number by one, which is intended. But, if a message is edited and then resent, its message number again - gets increased. This is because the script uses the same logic to + gets incrmented. This is because the script uses the same logic to process the edited message, which it uses to send the next message. - This minor bug is usually harmless, unless some special situations arise. - One such situation is when the first message in a thread is edited - and resent, and an `--in-reply-to` argument is also passed to send-email. + This minor bug is usually harmless, unless a special situations arises. + That situation is when the first message in a thread is edited and + resent, and an `--in-reply-to` argument is also passed to send-email. In this case, if the user has chosen shallow threading, the threading does not work as expected, and all messages become replies to the Message-ID specified in the `--in-reply-to` argument. @@ Commit message greater than 1, and the whole set of conditions is false. Therefore, the `$in_reply_to` variable remains as the first message's ID. This is what we expect in shallow threading. But if the user edits the first message - and resends it, the `$message_num` variable gets increased by 1, and + and resends it, the `$message_num` variable gets incremented by 1, and thus the condition `$message_num == 1` becomes false. This means that the `$in_reply_to` variable is not set to the first message's ID. As a result the next message in the thread is not a reply to the first @@ Commit message variable is set to the first message's ID, and the threading works as expected, regardless of the message number. - Just like the `$message_num` variable, the `$message_id_serial` variable - also increases by 1 whenever a new message is sent. This variable - displays the message number in the Message-ID of the email. - To fix this bug, we need to ensure that the `$message_num` variable is - not increased by 1 when a message is edited and resent. We do this by - decreasing both the `$message_num` and `$message_id_serial` variables - by 1 whenever the request to edit a message is received. This way, the - next message in the thread will have the same message number as the - edited message. Therefore the threading will work as expected. + not incremented by 1 when a message is edited and resent. We do this by + decreasing the `$message_num` variable by 1 whenever the request to edit + a message is received. This way, the next message in the thread will + have the same message number as the edited message. Therefore the + threading will work as expected. The same logic has also been applied in case the user drops a single message from the thread by choosing the "[n]o" option during @@ git-send-email.perl: sub send_message { + # the next message is treated as the successor to the + # previously sent message, and not the skipped message. + $message_num--; -+ $message_id_serial--; return 0; } elsif (/^e/i) { + # Since the same message will be sent again, we need to @@ git-send-email.perl: sub send_message { + # different message sent after the original non-edited + # message. + $message_num--; -+ $message_id_serial--; return -1; } elsif (/^q/i) { cleanup_compose_files(); 2: 6f2668de07 = 2: caf46596a7 send-email: show the new message id assigned by outlook in the logs -- 2.49.0.635.g48fa2f4343 ``` ## Aditya Garg, 2025-05-29 14:57 Subject: [PATCH v6 1/2] send-email: fix bug resulting in broken threads if a message is edited Message-ID: URL: https://gitlist.dev/e/d965439f76e341b97c8356e6d3c021532d4bcbeb.1748529954.git.gargaditya08%40live.com In-Reply-To: ``` Whenever we send a thread of emails using send-email, a message number is internally assigned to each email. This number is used to track the order of the emails in the thread. Whenever a new message is processed in a thread, the current script logic increments the message number by one, which is intended. But, if a message is edited and then resent, its message number again gets incrmented. This is because the script uses the same logic to process the edited message, which it uses to send the next message. This minor bug is usually harmless, unless a special situations arises. That situation is when the first message in a thread is edited and resent, and an `--in-reply-to` argument is also passed to send-email. In this case, if the user has chosen shallow threading, the threading does not work as expected, and all messages become replies to the Message-ID specified in the `--in-reply-to` argument. The reason for this bug is hidden in the code for threading itself. if ($thread) { if ($message_was_sent && ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 || $message_num == 1)) { $in_reply_to = $message_id; if (length $references > 0) { $references .= "\n $message_id"; } else { $references = "$message_id"; } } } Here `$message_num` is the current message number, and `$in_reply_to` is the Message-ID of the message to which the current message is a reply. In case `--in-reply-to` is specified, the `$in_reply_to` variable is set to the value of the `--in-reply-to` argument. Whenever this whole set of conditions is true, the script sets the `$in_reply_to` variable to the current message's ID. This is done to ensure that the next message in the thread is a reply to this message. In case we specify an `--in-reply-to` argument, and have shallow threading, the only condition that can make this true is `$message_num == 1`, which is true for the first message in a thread. Thus, the `$in_reply_to` variable gets set to the first message's ID. For subsequent messages, the `$message_num` variable is always greater than 1, and the whole set of conditions is false. Therefore, the `$in_reply_to` variable remains as the first message's ID. This is what we expect in shallow threading. But if the user edits the first message and resends it, the `$message_num` variable gets incremented by 1, and thus the condition `$message_num == 1` becomes false. This means that the `$in_reply_to` variable is not set to the first message's ID. As a result the next message in the thread is not a reply to the first message, but to the `--in-reply-to` argument, effectively breaking the threading. In case the user does not specify an `--in-reply-to` argument, the `!defined $in_reply_to` condition is true, and thus the `$in_reply_to` variable is set to the first message's ID, and the threading works as expected, regardless of the message number. To fix this bug, we need to ensure that the `$message_num` variable is not incremented by 1 when a message is edited and resent. We do this by decreasing the `$message_num` variable by 1 whenever the request to edit a message is received. This way, the next message in the thread will have the same message number as the edited message. Therefore the threading will work as expected. The same logic has also been applied in case the user drops a single message from the thread by choosing the "[n]o" option during confirmation. By doing this, the next message in the thread is assigned the message number of the dropped message, and thus the threading works as expected. Signed-off-by: Aditya Garg --- git-send-email.perl | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/git-send-email.perl b/git-send-email.perl index 55b7e00d29..ac1d5b7070 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1639,8 +1639,18 @@ sub send_message { default => $ask_default); die __("Send this email reply required") unless defined $_; if (/^n/i) { + # If we are skipping a message, we should make sure that + # the next message is treated as the successor to the + # previously sent message, and not the skipped message. + $message_num--; return 0; } elsif (/^e/i) { + # Since the same message will be sent again, we need to + # decrement the message number to the previous message. + # Otherwise, the edited message will be treated as a + # different message sent after the original non-edited + # message. + $message_num--; return -1; } elsif (/^q/i) { cleanup_compose_files(); -- 2.49.0.635.g48fa2f4343 ``` ## Aditya Garg, 2025-05-29 14:57 Subject: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs Message-ID: URL: https://gitlist.dev/e/caf46596a709df7205495b75da569baef2c7c9a2.1748529954.git.gargaditya08%40live.com In-Reply-To: ``` Whenever an email is sent, send-email shows a log at last, which contains all the headers of the email that were received by the receipients. In case outlook changes the Message-ID, a log for the same is shown to the user, but that change is not reflected when the log containing all the headers is displayed. Here is an example of the log that is shown when outlook changes the Message-ID: Outlook reassigned Message-ID to: OK. Log says: Server: smtp.office365.com MAIL FROM: RCPT TO: From: Aditya Garg To: negahe7142@nomrista.com Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs Date: Mon, 26 May 2025 20:28:36 +0530 Message-ID: <20250526145836.4825-1-gargaditya08@live.com> X-Mailer: git-send-email @GIT_VERSION@ MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Result: 250 This patch fixes this by modifying the $header variable, which is responsible for showing the logs at the end. Also, the log which states that the Message-ID has been changed will now be shown only when smtp-debug is enabled, since the main log having all of the headers is anyways displaying the new Message-ID. It should look like this after this patch: OK. Log says: Server: smtp.office365.com MAIL FROM: RCPT TO: From: Aditya Garg To: negahe7142@nomrista.com Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs Date: Mon, 26 May 2025 20:29:22 +0530 Message-ID: X-Mailer: git-send-email @GIT_VERSION@ MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Result: 250 Signed-off-by: Aditya Garg --- git-send-email.perl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl index ac1d5b7070..79d230448f 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1774,7 +1774,9 @@ sub send_message { if (is_outlook($smtp_server)) { if ($smtp->message =~ /<([^>]+)>/) { $message_id = "<$1>"; - printf __("Outlook reassigned Message-ID to: %s\n"), $message_id; + # Replace the original Message-ID in $header with the new one + $header =~ s/^(Message-ID:\s*).*\n/${1}$message_id\n/m; + printf __("Outlook reassigned Message-ID to: %s\n"), $message_id if $smtp->debug; } else { warn __("Warning: Could not retrieve Message-ID from server response.\n"); } -- 2.49.0.635.g48fa2f4343 ``` ## Junio C Hamano, 2025-05-29 16:01 Subject: Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs Message-ID: URL: https://gitlist.dev/e/xmqq5xhjmmno.fsf%40gitster.g In-Reply-To: ``` Aditya Garg writes: > This patch fixes this by modifying the $header variable, which is > responsible for showing the logs at the end. Also, the log which states > that the Message-ID has been changed will now be shown only when > smtp-debug is enabled, since the main log having all of the headers is > anyways displaying the new Message-ID. It should look like this after > this patch: We do not say "This patch does X" or "I do Y" when describing a change. Rather, you give an order to somebody who is modifying the codebase to "make it so". Something like ... Fix this by updating the $header variable, which has the message ID we internally assigned on the "Message-ID:" header, with the message ID the Outlook server assigned. The change itself looks good, but ... > + # Replace the original Message-ID in $header with the new one > + $header =~ s/^(Message-ID:\s*).*\n/${1}$message_id\n/m; ... is the comment adding any useful information over what the code already says? Will queue, with a typofix to "incrmented" in [1/2]. Thanks. ``` ## Aditya Garg, 2025-05-29 16:18 Subject: Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs Message-ID: URL: https://gitlist.dev/e/PN0PR01MB9588AF2A370D8A1F50745C97B866A%40PN0PR01MB9588.INDPRD01.PROD.OUTLOOK.COM In-Reply-To: ``` On 29/05/25 9:31 pm, Junio C Hamano wrote: > Aditya Garg writes: > >> This patch fixes this by modifying the $header variable, which is >> responsible for showing the logs at the end. Also, the log which states >> that the Message-ID has been changed will now be shown only when >> smtp-debug is enabled, since the main log having all of the headers is >> anyways displaying the new Message-ID. It should look like this after >> this patch: > > We do not say "This patch does X" or "I do Y" when describing a > change. Rather, you give an order to somebody who is modifying the > codebase to "make it so". Something like ... > > Fix this by updating the $header variable, which has the message > ID we internally assigned on the "Message-ID:" header, with the > message ID the Outlook server assigned. Ok. Want me to send another revision, or we good for now? > > The change itself looks good, but ... > >> + # Replace the original Message-ID in $header with the new one >> + $header =~ s/^(Message-ID:\s*).*\n/${1}$message_id\n/m; > > ... is the comment adding any useful information over what the code > already says? Considering the fact that making this regex what itself a pain, a small comment for readers doesn't hurt right? > > Will queue, with a typofix to "incrmented" in [1/2]. > > Thanks. ``` ## Junio C Hamano, 2025-06-04 12:32 Subject: Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs Message-ID: URL: https://gitlist.dev/e/xmqq8qm7g00q.fsf%40gitster.g In-Reply-To: ``` Aditya Garg writes: >> We do not say "This patch does X" or "I do Y" when describing a >> change. Rather, you give an order to somebody who is modifying the >> codebase to "make it so". Something like ... >> ... > Ok. Want me to send another revision, or we good for now? As the codebase will be frozen during the rc period, I am not in a hurry. But submitting hopefully a small and final reroll would be a good way to conclude the cycle. Thanks. ``` ## Aditya Garg, 2025-06-04 12:55 Subject: [PATCH v7 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix. Message-ID: URL: https://gitlist.dev/e/PN3PR01MB95979AA8114CA26405BE02CFB86CA%40PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM In-Reply-To: ``` Hi all, This patch series fixes two minor issues with git-send-email. The first patch fixes a bug that caused the message number to increase when a user edits an email. As a result of this bug, threads would break when a user edits an email. The second patch improves the logging of the new message ID assigned by Outlook when a user edits an email. v2 - Change the bugfix logic used to fix the threading bug. v3 - Add additional patch to improve the logging of the new message ID assigned by Outlook. v4 - Completely rewrite the commit message of the first patch to explain the bug in detail and how it is fixed. Also, add example logs to explain the second patch. v5 - Fix numerous spelling and grammatical errors in the commit message of the first patch. v6 - Change the subject of the first patch. - Prefer using "increment" instead of "increase" in the commit message of the first patch. - Avoid decreasing the `$message_id_serial` variable in the first patch. v7 - Remove unecessary comment in the second patch. - Mild rewording of the commit message of the second patch. - Fix incrmented -> incremented Aditya Garg (2): send-email: fix bug resulting in broken threads if a message is edited send-email: show the new message id assigned by outlook in the logs git-send-email.perl | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) Range-diff against v6: 1: a5dcec5428 ! 1: 05724ae6d3 send-email: fix bug resulting in broken threads if a message is edited @@ Commit message one, which is intended. But, if a message is edited and then resent, its message number again - gets incrmented. This is because the script uses the same logic to + gets incremented. This is because the script uses the same logic to process the edited message, which it uses to send the next message. This minor bug is usually harmless, unless a special situations arises. 2: 43227e8a5e ! 2: 360391c8e2 send-email: show the new message id assigned by outlook in the logs @@ Commit message Result: 250 - This patch fixes this by modifying the $header variable, which is - responsible for showing the logs at the end. Also, the log which states - that the Message-ID has been changed will now be shown only when - smtp-debug is enabled, since the main log having all of the headers is - anyways displaying the new Message-ID. It should look like this after - this patch: + Fix this by updating the $header variable, which has the message ID we + internally assigned on the "Message-ID:" header, with the message ID the + Outlook server assigned. It should look like this after this patch: OK. Log says: Server: smtp.office365.com @@ git-send-email.perl: sub send_message { if ($smtp->message =~ /<([^>]+)>/) { $message_id = "<$1>"; - printf __("Outlook reassigned Message-ID to: %s\n"), $message_id; -+ # Replace the original Message-ID in $header with the new one + $header =~ s/^(Message-ID:\s*).*\n/${1}$message_id\n/m; + printf __("Outlook reassigned Message-ID to: %s\n"), $message_id if $smtp->debug; } else { -- 2.49.0.windows.1 ``` ## Aditya Garg, 2025-06-04 12:55 Subject: [PATCH v7 2/2] send-email: show the new message id assigned by outlook in the logs Message-ID: URL: https://gitlist.dev/e/PN3PR01MB95979A02866CF1AD640E48ADB86CA%40PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM In-Reply-To: ``` Whenever an email is sent, send-email shows a log at last, which contains all the headers of the email that were received by the receipients. In case outlook changes the Message-ID, a log for the same is shown to the user, but that change is not reflected when the log containing all the headers is displayed. Here is an example of the log that is shown when outlook changes the Message-ID: Outlook reassigned Message-ID to: OK. Log says: Server: smtp.office365.com MAIL FROM: RCPT TO: From: Aditya Garg To: negahe7142@nomrista.com Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs Date: Mon, 26 May 2025 20:28:36 +0530 Message-ID: <20250526145836.4825-1-gargaditya08@live.com> X-Mailer: git-send-email @GIT_VERSION@ MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Result: 250 Fix this by updating the $header variable, which has the message ID we internally assigned on the "Message-ID:" header, with the message ID the Outlook server assigned. It should look like this after this patch: OK. Log says: Server: smtp.office365.com MAIL FROM: RCPT TO: From: Aditya Garg To: negahe7142@nomrista.com Subject: [PATCH] send-email: show the new message id assigned by outlook in the logs Date: Mon, 26 May 2025 20:29:22 +0530 Message-ID: X-Mailer: git-send-email @GIT_VERSION@ MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Result: 250 Signed-off-by: Aditya Garg --- git-send-email.perl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-send-email.perl b/git-send-email.perl index ac1d5b7070..175b0c184b 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1774,7 +1774,8 @@ sub send_message { if (is_outlook($smtp_server)) { if ($smtp->message =~ /<([^>]+)>/) { $message_id = "<$1>"; - printf __("Outlook reassigned Message-ID to: %s\n"), $message_id; + $header =~ s/^(Message-ID:\s*).*\n/${1}$message_id\n/m; + printf __("Outlook reassigned Message-ID to: %s\n"), $message_id if $smtp->debug; } else { warn __("Warning: Could not retrieve Message-ID from server response.\n"); } -- 2.49.0.windows.1 ``` ## Aditya Garg, 2025-06-04 12:55 Subject: [PATCH v7 1/2] send-email: fix bug resulting in broken threads if a message is edited Message-ID: URL: https://gitlist.dev/e/PN3PR01MB95977671AA4500599872A1A3B86CA%40PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM In-Reply-To: ``` Whenever we send a thread of emails using send-email, a message number is internally assigned to each email. This number is used to track the order of the emails in the thread. Whenever a new message is processed in a thread, the current script logic increments the message number by one, which is intended. But, if a message is edited and then resent, its message number again gets incremented. This is because the script uses the same logic to process the edited message, which it uses to send the next message. This minor bug is usually harmless, unless a special situations arises. That situation is when the first message in a thread is edited and resent, and an `--in-reply-to` argument is also passed to send-email. In this case, if the user has chosen shallow threading, the threading does not work as expected, and all messages become replies to the Message-ID specified in the `--in-reply-to` argument. The reason for this bug is hidden in the code for threading itself. if ($thread) { if ($message_was_sent && ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 || $message_num == 1)) { $in_reply_to = $message_id; if (length $references > 0) { $references .= "\n $message_id"; } else { $references = "$message_id"; } } } Here `$message_num` is the current message number, and `$in_reply_to` is the Message-ID of the message to which the current message is a reply. In case `--in-reply-to` is specified, the `$in_reply_to` variable is set to the value of the `--in-reply-to` argument. Whenever this whole set of conditions is true, the script sets the `$in_reply_to` variable to the current message's ID. This is done to ensure that the next message in the thread is a reply to this message. In case we specify an `--in-reply-to` argument, and have shallow threading, the only condition that can make this true is `$message_num == 1`, which is true for the first message in a thread. Thus, the `$in_reply_to` variable gets set to the first message's ID. For subsequent messages, the `$message_num` variable is always greater than 1, and the whole set of conditions is false. Therefore, the `$in_reply_to` variable remains as the first message's ID. This is what we expect in shallow threading. But if the user edits the first message and resends it, the `$message_num` variable gets incremented by 1, and thus the condition `$message_num == 1` becomes false. This means that the `$in_reply_to` variable is not set to the first message's ID. As a result the next message in the thread is not a reply to the first message, but to the `--in-reply-to` argument, effectively breaking the threading. In case the user does not specify an `--in-reply-to` argument, the `!defined $in_reply_to` condition is true, and thus the `$in_reply_to` variable is set to the first message's ID, and the threading works as expected, regardless of the message number. To fix this bug, we need to ensure that the `$message_num` variable is not incremented by 1 when a message is edited and resent. We do this by decreasing the `$message_num` variable by 1 whenever the request to edit a message is received. This way, the next message in the thread will have the same message number as the edited message. Therefore the threading will work as expected. The same logic has also been applied in case the user drops a single message from the thread by choosing the "[n]o" option during confirmation. By doing this, the next message in the thread is assigned the message number of the dropped message, and thus the threading works as expected. Signed-off-by: Aditya Garg --- git-send-email.perl | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/git-send-email.perl b/git-send-email.perl index 55b7e00d29..ac1d5b7070 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -1639,8 +1639,18 @@ sub send_message { default => $ask_default); die __("Send this email reply required") unless defined $_; if (/^n/i) { + # If we are skipping a message, we should make sure that + # the next message is treated as the successor to the + # previously sent message, and not the skipped message. + $message_num--; return 0; } elsif (/^e/i) { + # Since the same message will be sent again, we need to + # decrement the message number to the previous message. + # Otherwise, the edited message will be treated as a + # different message sent after the original non-edited + # message. + $message_num--; return -1; } elsif (/^q/i) { cleanup_compose_files(); -- 2.49.0.windows.1 ``` ## Aditya Garg, 2025-06-04 12:55 Subject: Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs Message-ID: URL: https://gitlist.dev/e/PN3PR01MB95978CC57C19CD03B67EB782B86CA%40PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM In-Reply-To: ``` On 04-06-2025 06:02 pm, Junio C Hamano wrote: > Aditya Garg writes: > >>> We do not say "This patch does X" or "I do Y" when describing a >>> change. Rather, you give an order to somebody who is modifying the >>> codebase to "make it so". Something like ... >>> ... >> Ok. Want me to send another revision, or we good for now? > > As the codebase will be frozen during the rc period, I am not in a > hurry. But submitting hopefully a small and final reroll would be a > good way to conclude the cycle. Sent ``` ## Junio C Hamano, 2025-06-04 16:31 Subject: Re: [PATCH v7 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix. Message-ID: URL: https://gitlist.dev/e/xmqqplfjbh9s.fsf%40gitster.g In-Reply-To: ``` Aditya Garg writes: > v7 - Remove unecessary comment in the second patch. > - Mild rewording of the commit message of the second patch. > - Fix incrmented -> incremented Looking good. Will queue. Thanks. ```