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]

 




> On 24 May 2025, at 5:08 AM, Jacob Keller <jacob.e.keller@xxxxxxxxx> wrote:
> 
> 
> 
>> 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..

I thought that was intended, not it doesn't seem like that to me.




[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