[PATCH v4 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.

[PATCH v4 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.

[Aditya Garg]

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 <gargaditya08@live.com>
     
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: <PN3PR01MB95973E5ACD7CCFADCB4E298CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
    +    OK. Log says:
    +    Server: smtp.office365.com
    +    MAIL FROM:<gargaditya08@live.com>
    +    RCPT TO:<negahe7142@nomrista.com>
    +    From: Aditya Garg <gargaditya08@live.com>
    +    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:<gargaditya08@live.com>
    +    RCPT TO:<negahe7142@nomrista.com>
    +    From: Aditya Garg <gargaditya08@live.com>
    +    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: <PN3PR01MB95977486061BD2542BD09B67B865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
    +    X-Mailer: git-send-email @GIT_VERSION@
    +    MIME-Version: 1.0
    +    Content-Transfer-Encoding: 8bit
    +
    +    Result: 250
     
         Signed-off-by: Aditya Garg <gargaditya08@live.com>
     
-- 
2.43.0

[PATCH v4 1/2] send-email: fix bug resulting in increased message number if a message is edited

[Aditya Garg]

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 <gargaditya08@live.com>
---
 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

[PATCH v4 2/2] send-email: show the new message id assigned by outlook in the logs

[Aditya Garg]

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: <PN3PR01MB95973E5ACD7CCFADCB4E298CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
OK. Log says:
Server: smtp.office365.com
MAIL FROM:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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: <PN3PR01MB95977486061BD2542BD09B67B865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
X-Mailer: git-send-email @GIT_VERSION@
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Result: 250

Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
 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

[PATCH v5 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.

[Aditya Garg]

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.

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:  63addf9d9b ! 1:  5103ea4034 send-email: fix bug resulting in increased message number if a message is edited
    @@ Commit message
     
         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.
    +    process the edited message, which it uses to send the next message.
     
    -    This minor bug is usually harmless unless some special situations arise.
    +    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
    +    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.
    @@ Commit message
                 }
         }
     
    -    Here $message_num is the current message number, and $in_reply_to is
    +    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.
    @@ Commit 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.
    +    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.
    +    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
    +    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`
    +    `!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.
    +    as expected, regardless of the message number.
     
    -    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.
    +    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.
     
    -    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.
    +    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.
     
         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
2:  72b3cd1bfb = 2:  6f2668de07 send-email: show the new message id assigned by outlook in the logs
-- 
2.43.0

[PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited

[Aditya Garg]

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 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.
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 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. 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.

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.

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 <gargaditya08@live.com>
---
 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

[PATCH v5 2/2] send-email: show the new message id assigned by outlook in the logs

[Aditya Garg]

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: <PN3PR01MB95973E5ACD7CCFADCB4E298CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
OK. Log says:
Server: smtp.office365.com
MAIL FROM:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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: <PN3PR01MB95977486061BD2542BD09B67B865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
X-Mailer: git-send-email @GIT_VERSION@
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Result: 250

Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
 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

Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited

[Junio C Hamano]

Aditya Garg <gargaditya08@live.com> writes:

> Subject: Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited

Is this the same title Kristoffer said that it does not give much
meaningful information, to which you said you "have re-written the
whole message"?

cf. <PN3PR01MB95973C8CEC731B43816AB38CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>

> 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 it uses to send the next message.

"increase" -> "increment" is more common to count up by one.

> This minor bug is usually harmless, unless some special situations arise.
> One such situation is when the first message in a thread is edited

Which makes it sound like you know of more than one bug but only
telling us about "one such situation" here.  If so, what are others?
If not, the phrasing in this paragraph is somewhat misleading.

> 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.

OK.

> 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.

Hmph, isn't it more like "after editing Nth message, we re-process
that edited message, and we used to call that edited message N+1th,
which was wrong.  We now keep the same numbering and call the edited
message Nth (and the version before editing we didn't send, so there
is no risk of sending two Nth messages)"?  

> 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.

OK.

The above explains why the patch needs to touch message_num.  It
would be evfen better if it described what the variable is used for,
exactly.

    Side note: during the initial round of this change, I explained
    that $num_sent is the counter in the batch we are sending out
    (hence it is reset to 0 when a batch fills and the next batch
    starts).  If there is a similar concise and clear explanation of
    what $message_num?  "The number, counting from 1, of the message
    in the set of messages we are sending", or something, perhaps?

And none of the above justifies why this patch mucks with
message_id_serial.  Should it always be the same as message_num (in
which case the natural question is "why do we need both?")?

If we can prove that message_num and message_id_serial must be
incremented in sync, it is OK to have a separate topic that unifies
these two variables into just a single message_num, but I'd prefer
not to see message_id_serial mentioned above and touched below at
all in this patch to fix the in_reply_to issue.

> Signed-off-by: Aditya Garg <gargaditya08@live.com>
> ---
>  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();

Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited

[Aditya Garg]

> On 29 May 2025, at 4:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Aditya Garg <gargaditya08@live.com> writes:
> 
>> Subject: Re: [PATCH v5 1/2] send-email: fix bug resulting in increased message number if a message is edited
> 
> Is this the same title Kristoffer said that it does not give much
> meaningful information, to which you said you "have re-written the
> whole message"?

I understood it as needing rewrite only of the body, and not the subject.
> 
> cf. <PN3PR01MB95973C8CEC731B43816AB38CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
> 
>> 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 it uses to send the next message.
> 
> "increase" -> "increment" is more common to count up by one.
Ok
> 
>> This minor bug is usually harmless, unless some special situations arise.
>> One such situation is when the first message in a thread is edited
> 
> Which makes it sound like you know of more than one bug but only
> telling us about "one such situation" here.  If so, what are others?
> If not, the phrasing in this paragraph is somewhat misleading.

I'll change it.

>> 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.
> 
> OK.
> 
>> 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.
> 
> Hmph, isn't it more like "after editing Nth message, we re-process
> that edited message, and we used to call that edited message N+1th,
> which was wrong.  We now keep the same numbering and call the edited
> message Nth (and the version before editing we didn't send, so there
> is no risk of sending two Nth messages)"?  

Yes

> 
>> 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.
> 
> OK.
> 
> The above explains why the patch needs to touch message_num.  It
> would be evfen better if it described what the variable is used for,
> exactly.

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.

I had explained this in the starting.

> 
>    Side note: during the initial round of this change, I explained
>    that $num_sent is the counter in the batch we are sending out
>    (hence it is reset to 0 when a batch fills and the next batch
>    starts).  If there is a similar concise and clear explanation of
>    what $message_num?  "The number, counting from 1, of the message
>    in the set of messages we are sending", or something, perhaps?
> 
> And none of the above justifies why this patch mucks with
> message_id_serial.  Should it always be the same as message_num (in
> which case the natural question is "why do we need both?")?

I had the similar question as well, but it also has special cases.

In case a person starts a thread using the --thread option of format-patch
and by mistake deletes the message id header of a patch, the serial number
starts with one from that patch.

Although honestly speaking, I myself am getting more confused as far as
serial number is concerned, and I think its best to drop it since its not a
breaking change unlike message number. It's just to ensure a unique message
ID to all patches, and having incremented numbers is ok.

Message number definitely needs a fix since it breaks threads.

> If we can prove that message_num and message_id_serial must be
> incremented in sync, it is OK to have a separate topic that unifies
> these two variables into just a single message_num, but I'd prefer
> not to see message_id_serial mentioned above and touched below at
> all in this patch to fix the in_reply_to issue.
> 
>> Signed-off-by: Aditya Garg <gargaditya08@live.com>
>> ---
>> 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();

[PATCH v6 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.

[Aditya Garg]

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 <gargaditya08@live.com>
     
      ## 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

[PATCH v6 1/2] send-email: fix bug resulting in broken threads if a message is edited

[Aditya Garg]

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 <gargaditya08@live.com>
---
 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

[PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs

[Aditya Garg]

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: <PN3PR01MB95973E5ACD7CCFADCB4E298CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
OK. Log says:
Server: smtp.office365.com
MAIL FROM:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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: <PN3PR01MB95977486061BD2542BD09B67B865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
X-Mailer: git-send-email @GIT_VERSION@
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Result: 250

Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
 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

Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs

[Junio C Hamano]

Aditya Garg <gargaditya08@live.com> 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.

Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs

[Aditya Garg]

On 29/05/25 9:31 pm, Junio C Hamano wrote:
> Aditya Garg <gargaditya08@live.com> 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.

Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs

[Junio C Hamano]

Aditya Garg <gargaditya08@live.com> 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.

[PATCH v7 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.

[Aditya Garg]

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

[PATCH v7 1/2] send-email: fix bug resulting in broken threads if a message is edited

[Aditya Garg]

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 <gargaditya08@live.com>
---
 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

[PATCH v7 2/2] send-email: show the new message id assigned by outlook in the logs

[Aditya Garg]

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: <PN3PR01MB95973E5ACD7CCFADCB4E298CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
OK. Log says:
Server: smtp.office365.com
MAIL FROM:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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:<gargaditya08@live.com>
RCPT TO:<negahe7142@nomrista.com>
From: Aditya Garg <gargaditya08@live.com>
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: <PN3PR01MB95977486061BD2542BD09B67B865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
X-Mailer: git-send-email @GIT_VERSION@
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Result: 250

Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
 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

Re: [PATCH v6 2/2] send-email: show the new message id assigned by outlook in the logs

[Aditya Garg]

On 04-06-2025 06:02 pm, Junio C Hamano wrote:
> Aditya Garg <gargaditya08@live.com> 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

Re: [PATCH v7 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.

[Junio C Hamano]

Aditya Garg <gargaditya08@live.com> 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.