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

From: Junio C Hamano <gitster@pobox.com>
Date: May 23, 2025, 22:19 UTC
Message-ID: <xmqqwma7ug13.fsf@gitster.g>
In-Reply-To: <73234CC5-8712-4B7B-94BE-F643345677BD@live.com>

Aditya Garg <gargaditya08@live.com> writes:

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

The reverse is not always true, though.

Show 7 quoted lines

> 	# 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 ...

Show 10 quoted lines

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