[PATCH] send-email: fix bug breaking shallow threading if the first patch is edited

From: Aditya Garg <gargaditya08@live.com>
Date: May 23, 2025, 15:36 UTC
Message-ID: <73234CC5-8712-4B7B-94BE-F643345677BD@live.com>

There is a bug in send-email that turns off shallow threading if some special conditions are there. Those conditions are:

1. An --in-reply-to must be specified when sending the patch
2. When asked for confirmation before sending the first patch, the
  user must edit the patch (pressing e and enter).

If these two conditions are fulfilled, the threading will turn off and all subsequent messages will become as replies to the Message-ID set in --in-reply-to, rather than becoming replies to the first patch.

The cause of this bug was very simple. There are many conditions that determine whether threading should be done or not. The relevant ones for this case are:

1. --in-reply-to is not defined
2. $message_num is 1

If ANY ONE of these is fulfilled, threading will occur. Now, in our case, we have defined an --in-reply-to, so condition 1 is not fulfilled, and thus is omitted out. The only condition that can enable threading is $message_num being 1. As far as I understand, this condition was based on the assumption that the first message being send will have $message_num as 1, since in case of shallow threads, we just set in-reply-to only for the Message-ID of the first patch sent. But, in case we edit a patch, its $message_num increases by one, and thus, our second condition for threading is also not fulfilled, thus turning off threading.

Luckily, the script also keeps count of the number of messages actually sent using the $num_sent variable. This was implemented for people who have set a particular batch size for emails. This is a more reliable indicator to track the actual first patch.

So, whenever the first patch is sent, $num_sent will become 1. If we replace the condition to use threading from $message_num to $num_sent=1, it will always be fulfilled irrespective of whether the user edits the first patch or not, and thus threading will turn on.

This bug will not be triggered if --in-reply-to is not set, because the first condition (not having an --in-reply-to) gets fulfilled, so the script doesn't care what $message_num is there.

Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 55b7e00d29..2cfd61b4b9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -2041,10 +2041,11 @@ sub process_file {
	}

	# set up for the next message
+	$num_sent++;
	if ($thread) {
		if ($message_was_sent &&
		  ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 ||
-		  $message_num == 1)) {
+		  $num_sent == 1)) {
			$in_reply_to = $message_id;
			if (length $references > 0) {
				$references .= "\n $message_id";
@@ -2060,7 +2061,6 @@ sub process_file {
		$references = '';
	}
	$message_id = undef;
-	$num_sent++;
	if (defined $batch_size && $num_sent == $batch_size) {
		$num_sent = 0;
		$smtp->quit if defined $smtp;

-- 
2.43.0