> On 26 May 2025, at 12:35 AM, Aditya Garg <adityagarg1208@xxxxxxxxx> wrote: > > > >> On 26/05/25 12:19 am, Kristoffer Haugsbakk wrote: >> Hi >> >>> send-email: fix bug resulting in increased message number if a message is edited >> >> I don’t understand what the bug is from the title. “Message number” >> sounds harmless. It breaks the threading? The summary/subject could >> say that instead. Fix threading bug. >> >>> On Sun, May 25, 2025, at 19:12, Aditya Garg wrote: >>> In case a message is edited before it is sent, its message number gets >>> increased by 1, and so does its order in the message id. >> >> It feels like this part about increasing by one and if-editing gets >> repeated at least two times in this paragraph. >> >>> The cause of this bug was that when a person attempts to edit the >>> message, the whole sub process_file gets terminated, and the user is >>> asked to edit the message. >> >> Here’s the repetition. >> >> Also I am not familiar with the code. Just testing it I get this `6` here: >> >> Message-ID: <20250525181003.40129-6-kristofferhaugsbakk@xxxxxxxxxxxx> >> >> Which was incremented every time I did an edit with: >> >> send-email --suppress-cc=all --to=<me> \ >> --confirm=always one two >> >> But that turned out to be benign in my simple case since the next email >> used the correct In-Reply-To. >> >> So at this point (reading the paragraph) I don’t know what the bug is. >> >>> After necessary edits are done, the whole sub process_file is executed again. >>> The way sub process_file is designed, every time is runs, it increases the >>> $message_num variable by 1. The reason for this was that the function ran >>> again everytime a next message was sent in a thread, and thus we need to >>> increase the message number for that message. In case a user edits the message, >>> there is no check for the same and the new message gets treated as a subsequent >>> message of a thread, therefore increasing its message number by one. >> >> This feels like repetition again. You say that a variable is >> incremented because the message is edited. >> >>> This breaks the shallow thread logic which relies on $message_num >>> being 1 for the first message, and it gets changed in case the user >>> edits the first message. >> >> If I’m right in my assumption that this number is the `4` here: >> >> Message-ID: <20250525182426.41076-4-kristofferhaugsbakk@xxxxxxxxxxxx> >> >> This was the first proposed email I got with “shallow thread” (all in >> reply to first): >> >> git send-email --suppress-cc=all --to=<me> \ >> --thread --no-chain-reply-to --confirm=always one two three >> >> Then I edit all the messages. They still all manage to refer to the >> first message id in the thread. >> >> I still don’t understand what the bug is. > > Steps to reproduce: > > 1. Run `git send-email --to=someone@xxxxxxxxxxx HEAD~3 --in-reply-to=some_message_id` You didn't specify --in-reply-to in your command > > 2. Edit the first patch (pressing e and enter) when send-email asks for confirmation. > (You may have to set confirm = always) > > 3. Do the edits. The message id of the first patch should have 2 instead of 1. If yes, > send all the messages and watch the threads break. You also didn't edit the first patch, and rather edited some other one?
