{"thread":{"id":"63521","subject":"Re: [PATCH v3 1/2] send-email: fix bug resulting in increased message number if a message is edited","startedAt":"2025-05-25T19:05:23Z","lastAt":"2025-05-25T19:07:15Z","messageCount":2,"participants":["Aditya Garg"],"isPatch":true,"patchVersion":3,"patchTotal":2},"messages":[{"id":"518878","messageId":"32479CC9-3C03-4F3F-A57B-88A3D43305CA@gmail.com","threadId":"63521","inReplyTo":null,"subject":"Re: [PATCH v3 1/2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Aditya Garg","fromEmail":"adityagarg1208@gmail.com","sentAt":"2025-05-25T19:05:07Z","receivedAt":"2025-05-25T19:05:23Z","isPatch":true,"sender":{"key":"adityagarg1208@gmail.com","avatar":null},"body":"\n\nOn 26/05/25 12:19 am, Kristoffer Haugsbakk wrote:\n> Hi\n> \n>> send-email: fix bug resulting in increased message number if a message is edited\n> \n> I don’t understand what the bug is from the title. “Message number”\n> sounds harmless. It breaks the threading? The summary/subject could\n> say that instead. Fix threading bug.\n> \n> On Sun, May 25, 2025, at 19:12, Aditya Garg wrote:\n>> In case a message is edited before it is sent, its message number gets\n>> increased by 1, and so does its order in the message id.\n> \n> It feels like this part about increasing by one and if-editing gets\n> repeated at least two times in this paragraph.\n> \n>> The cause of this bug was that when a person attempts to edit the\n>> message, the whole sub process_file gets terminated, and the user is\n>> asked to edit the message.\n> \n> Here’s the repetition.\n> \n> Also I am not familiar with the code. Just testing it I get this `6` here:\n> \n> Message-ID: <20250525181003.40129-6-kristofferhaugsbakk@fastmail.com>\n> \n> Which was incremented every time I did an edit with:\n> \n> send-email --suppress-cc=all --to= \\\n> --confirm=always one two\n> \n> But that turned out to be benign in my simple case since the next email\n> used the correct In-Reply-To.\n> \n> So at this point (reading the paragraph) I don’t know what the bug is.\n> \n>> After necessary edits are done, the whole sub process_file is executed again.\n>> The way sub process_file is designed, every time is runs, it increases the\n>> $message_num variable by 1. The reason for this was that the function ran\n>> again everytime a next message was sent in a thread, and thus we need to\n>> increase the message number for that message. In case a user edits the message,\n>> there is no check for the same and the new message gets treated as a subsequent\n>> message of a thread, therefore increasing its message number by one.\n> \n> This feels like repetition again. You say that a variable is\n> incremented because the message is edited.\n> \n>> This breaks the shallow thread logic which relies on $message_num\n>> being 1 for the first message, and it gets changed in case the user\n>> edits the first message.\n> \n> If I’m right in my assumption that this number is the `4` here:\n> \n> Message-ID: <20250525182426.41076-4-kristofferhaugsbakk@fastmail.com>\n> \n> This was the first proposed email I got with “shallow thread” (all in\n> reply to first):\n> \n> git send-email --suppress-cc=all --to= \\\n> --thread --no-chain-reply-to --confirm=always one two three\n> \n> Then I edit all the messages. They still all manage to refer to the\n> first message id in the thread.\n> \n> I still don’t understand what the bug is.\n\nSteps to reproduce:\n\n1. Run `git send-email --to=someone@example.com HEAD~3 --in-reply-to=some_message_id`\n\n2. Edit the first patch (pressing e and enter) when send-email asks for confirmation.\n(You may have to set confirm = always)\n\n3. Do the edits. The message id of the first patch should have 2 instead of 1. If yes,\nsend all the messages and watch the threads break.\n> \n> ❦\n> \n> $ git diagnose\n> Collecting diagnostic info\n> \n> git version 2.49.0.780.g892193c3f50\n> cpu: x86_64\n> built from commit: 892193c3f509fb8a9e4e7a5a19a2e24137befda8\n> sizeof-long: 8\n> sizeof-size_t: 8\n> shell-path: /bin/sh\n> libcurl: 7.81.0\n> OpenSSL: OpenSSL 3.0.2 15 Mar 2022\n> zlib: 1.2.11\n> SHA-1: SHA1_DC\n> SHA-256: SHA256_BLK\n> Repository root: /home/kristoffer/programming/git\n> Available space on '/home/kristoffer/programming/git': 200.56 GiB (mount flags 0x1000)\n\n"},{"id":"518879","messageId":"CDD9EC9A-3703-4826-B7D2-45237A2A4031@gmail.com","threadId":"63521","inReplyTo":"32479CC9-3C03-4F3F-A57B-88A3D43305CA@gmail.com","subject":"Re: [PATCH v3 1/2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Aditya Garg","fromEmail":"adityagarg1208@gmail.com","sentAt":"2025-05-25T19:07:01Z","receivedAt":"2025-05-25T19:07:15Z","isPatch":true,"sender":{"key":"adityagarg1208@gmail.com","avatar":null},"body":"\n\n> On 26 May 2025, at 12:35 AM, Aditya Garg wrote:\n> \n> \n> \n>> On 26/05/25 12:19 am, Kristoffer Haugsbakk wrote:\n>> Hi\n>> \n>>> send-email: fix bug resulting in increased message number if a message is edited\n>> \n>> I don’t understand what the bug is from the title. “Message number”\n>> sounds harmless. It breaks the threading? The summary/subject could\n>> say that instead. Fix threading bug.\n>> \n>>> On Sun, May 25, 2025, at 19:12, Aditya Garg wrote:\n>>> In case a message is edited before it is sent, its message number gets\n>>> increased by 1, and so does its order in the message id.\n>> \n>> It feels like this part about increasing by one and if-editing gets\n>> repeated at least two times in this paragraph.\n>> \n>>> The cause of this bug was that when a person attempts to edit the\n>>> message, the whole sub process_file gets terminated, and the user is\n>>> asked to edit the message.\n>> \n>> Here’s the repetition.\n>> \n>> Also I am not familiar with the code. Just testing it I get this `6` here:\n>> \n>> Message-ID: <20250525181003.40129-6-kristofferhaugsbakk@fastmail.com>\n>> \n>> Which was incremented every time I did an edit with:\n>> \n>> send-email --suppress-cc=all --to= \\\n>> --confirm=always one two\n>> \n>> But that turned out to be benign in my simple case since the next email\n>> used the correct In-Reply-To.\n>> \n>> So at this point (reading the paragraph) I don’t know what the bug is.\n>> \n>>> After necessary edits are done, the whole sub process_file is executed again.\n>>> The way sub process_file is designed, every time is runs, it increases the\n>>> $message_num variable by 1. The reason for this was that the function ran\n>>> again everytime a next message was sent in a thread, and thus we need to\n>>> increase the message number for that message. In case a user edits the message,\n>>> there is no check for the same and the new message gets treated as a subsequent\n>>> message of a thread, therefore increasing its message number by one.\n>> \n>> This feels like repetition again. You say that a variable is\n>> incremented because the message is edited.\n>> \n>>> This breaks the shallow thread logic which relies on $message_num\n>>> being 1 for the first message, and it gets changed in case the user\n>>> edits the first message.\n>> \n>> If I’m right in my assumption that this number is the `4` here:\n>> \n>> Message-ID: <20250525182426.41076-4-kristofferhaugsbakk@fastmail.com>\n>> \n>> This was the first proposed email I got with “shallow thread” (all in\n>> reply to first):\n>> \n>> git send-email --suppress-cc=all --to= \\\n>> --thread --no-chain-reply-to --confirm=always one two three\n>> \n>> Then I edit all the messages. They still all manage to refer to the\n>> first message id in the thread.\n>> \n>> I still don’t understand what the bug is.\n> \n> Steps to reproduce:\n> \n> 1. Run `git send-email --to=someone@example.com HEAD~3 --in-reply-to=some_message_id`\n\nYou didn't specify --in-reply-to in your command\n> \n> 2. Edit the first patch (pressing e and enter) when send-email asks for confirmation.\n> (You may have to set confirm = always)\n> \n> 3. Do the edits. The message id of the first patch should have 2 instead of 1. If yes,\n> send all the messages and watch the threads break.\n\nYou also didn't edit the first patch, and rather edited some other one?"}]}