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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>
---
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






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux