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` 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. > > ❦ > > $ git diagnose > Collecting diagnostic info > > git version 2.49.0.780.g892193c3f50 > cpu: x86_64 > built from commit: 892193c3f509fb8a9e4e7a5a19a2e24137befda8 > sizeof-long: 8 > sizeof-size_t: 8 > shell-path: /bin/sh > libcurl: 7.81.0 > OpenSSL: OpenSSL 3.0.2 15 Mar 2022 > zlib: 1.2.11 > SHA-1: SHA1_DC > SHA-256: SHA256_BLK > Repository root: /home/kristoffer/programming/git > Available space on '/home/kristoffer/programming/git': 200.56 GiB (mount flags 0x1000)
