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
