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

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