git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jacob Keller <jacob.e.keller@intel.com>
Date
May 23, 2025, 23:37 UTC
Message-ID
<4dbb0dc7-52ef-4ffe-9215-de94fb448234@intel.com>
In-Reply-To
<73234CC5-8712-4B7B-94BE-F643345677BD@live.com>
On 5/23/2025 8:36 AM, Aditya Garg wrote:
Show 30 quoted lines
> 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..

Show 11 quoted lines
> 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.

Previous: Junio C HamanoNext: Aditya Garg
Message 4 of 10 in “send-email: fix bug breaking shallow threading if the first patch is edited”
  1. send-email: fix bug breaking shallow threading if the first patch is editedAditya Garg, May 23, 2025
  2. Aditya GargMay 23, 2025
  3. Junio C HamanoMay 23, 2025
  4. Jacob KellerMay 23, 2025
  5. send-email: fix bug resulting in increased message number if a message is editedAditya Garg, May 24, 2025
  6. 0/2 send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.Aditya Garg, May 25, 2025
  7. 1/2 send-email: fix bug resulting in increased message number if a message is editedAditya Garg, May 25, 2025
  8. Kristoffer HaugsbakkMay 25, 2025
  9. Aditya GargMay 26, 2025
  10. 2/2 send-email: show the new message id assigned by outlook in the logsAditya Garg, May 25, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.