On 5/23/2025 8:36 AM, Aditya Garg wrote: > 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. > Why does editing a message change the message_num??? That feels like the real bug to me.. > 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. > Just from reading the commit message, this smells like a hack or workaround to me. I don't fully understand the logic in place as-is, and I think using num_sent is a bit of a weird way to resolve this.
