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

> On 24 May 2025, at 3:49 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> 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.
> 
>>    # 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?
>