> On 24 May 2025, at 3:49 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> 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?
>
Hmm, you are right, that's a problem. I think we need to fix message
number then.
