Re: [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]

 



Aditya Garg <gargaditya08@xxxxxxxx> writes:

> So, whenever the first patch is sent, $num_sent will become 1.

The reverse is not always true, though.

> 	# 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)) {

This sais "enter this block if we have sent a message and one of
(num_set is 1, or we are told to chain-reply-to, or we do not have
in-reply-to) holds true".

But is $num_set == 1 really limited to "the first message"?  Given
that ...

> 			$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;

... the counter is reset when we send out the batch_size message
(and we sleep in this block, which is outside the post-context of
this hunk).  So when you send the first message of the next batch,
you'd do the same, no?  By that time, we have in_reply_to set, but
that does not prevent from $num_sent, which was reset to 0 at the
batch boundary and then incremented to 1, to reenter the block in
the first hunk, no?

> 		$smtp->quit if defined $smtp;




[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