{"thread":{"id":"63508","subject":"[PATCH] send-email: fix bug breaking shallow threading if the first patch is edited","startedAt":"2025-05-23T15:36:23Z","lastAt":"2025-05-26T15:54:30Z","messageCount":10,"participants":["Aditya Garg","Junio C Hamano","Jacob Keller","Kristoffer Haugsbakk"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"518772","messageId":"73234CC5-8712-4B7B-94BE-F643345677BD@live.com","threadId":"63508","inReplyTo":null,"subject":"[PATCH] send-email: fix bug breaking shallow threading if the first patch is edited","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-23T15:36:19Z","receivedAt":"2025-05-23T15:36:23Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"There is a bug in send-email that turns off shallow threading if\nsome special conditions are there. Those conditions are:\n\n1. An --in-reply-to must be specified when sending the patch\n2. When asked for confirmation before sending the first patch, the\n user must edit the patch (pressing e and enter).\n\nIf these two conditions are fulfilled, the threading will turn off\nand all subsequent messages will become as replies to the\nMessage-ID set in --in-reply-to, rather than becoming replies to\nthe first patch.\n\nThe cause of this bug was very simple. There are many conditions\nthat determine whether threading should be done or not. The\nrelevant ones for this case are:\n\n1. --in-reply-to is not defined\n2. $message_num is 1\n\nIf ANY ONE of these is fulfilled, threading will occur. Now, in\nour case, we have defined an --in-reply-to, so condition 1 is\nnot fulfilled, and thus is omitted out. The only condition that\ncan enable threading is $message_num being 1. As far as I\nunderstand, this condition was based on the assumption that the\nfirst message being send will have $message_num as 1, since in\ncase of shallow threads, we just set in-reply-to only for the\nMessage-ID of the first patch sent. But, in case we edit a patch,\nits $message_num increases by one, and thus, our second condition\nfor threading is also not fulfilled, thus turning off threading.\n\nLuckily, the script also keeps count of the number of messages\nactually sent using the $num_sent variable. This was implemented\nfor people who have set a particular batch size for emails. This\nis a more reliable indicator to track the actual first patch.\n\nSo, whenever the first patch is sent, $num_sent will become 1.\nIf we replace the condition to use threading from $message_num\nto $num_sent=1, it will always be fulfilled irrespective of\nwhether the user edits the first patch or not, and thus threading\nwill turn on.\n\nThis bug will not be triggered if --in-reply-to is not set,\nbecause the first condition (not having an --in-reply-to) gets\nfulfilled, so the script doesn't care what $message_num is there.\n\nSigned-off-by: Aditya Garg \n---\ngit-send-email.perl | 4 ++--\n1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 55b7e00d29..2cfd61b4b9 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -2041,10 +2041,11 @@ sub process_file {\n\t}\n\n\t# set up for the next message\n+\t$num_sent++;\n\tif ($thread) {\n\t\tif ($message_was_sent &&\n\t\t ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 ||\n-\t\t $message_num == 1)) {\n+\t\t $num_sent == 1)) {\n\t\t\t$in_reply_to = $message_id;\n\t\t\tif (length $references > 0) {\n\t\t\t\t$references .= \"\\n $message_id\";\n@@ -2060,7 +2061,6 @@ sub process_file {\n\t\t$references = '';\n\t}\n\t$message_id = undef;\n-\t$num_sent++;\n\tif (defined $batch_size && $num_sent == $batch_size) {\n\t\t$num_sent = 0;\n\t\t$smtp->quit if defined $smtp;\n-- \n2.43.0\n\n"},{"id":"518773","messageId":"7077A82F-C1ED-4F67-9E85-94E42FA25FD4@live.com","threadId":"63508","inReplyTo":"73234CC5-8712-4B7B-94BE-F643345677BD@live.com","subject":"Re: [PATCH] send-email: fix bug breaking shallow threading if the first patch is edited","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-23T15:44:33Z","receivedAt":"2025-05-23T15:44:39Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"\n\n> On 23 May 2025, at 9:06 PM, Aditya Garg wrote:\n> \n> There is a bug in send-email that turns off shallow threading if\n> some special conditions are there. Those conditions are:\n> \n> 1. An --in-reply-to must be specified when sending the patch\n> 2. When asked for confirmation before sending the first patch, the\n> user must edit the patch (pressing e and enter).\n> \n> If these two conditions are fulfilled, the threading will turn off\n> and all subsequent messages will become as replies to the\n> Message-ID set in --in-reply-to, rather than becoming replies to\n> the first patch.\n> \n> The cause of this bug was very simple. There are many conditions\n> that determine whether threading should be done or not. The\n> relevant ones for this case are:\n> \n> 1. --in-reply-to is not defined\n> 2. $message_num is 1\n> \n> If ANY ONE of these is fulfilled, threading will occur. Now, in\n> our case, we have defined an --in-reply-to, so condition 1 is\n> not fulfilled, and thus is omitted out. The only condition that\n> can enable threading is $message_num being 1. As far as I\n> understand, this condition was based on the assumption that the\n> first message being send will have $message_num as 1, since in\n> case of shallow threads, we just set in-reply-to only for the\n> Message-ID of the first patch sent. But, in case we edit a patch,\n> its $message_num increases by one, and thus, our second condition\n> for threading is also not fulfilled, thus turning off threading.\n> \n> Luckily, the script also keeps count of the number of messages\n> actually sent using the $num_sent variable. This was implemented\n> for people who have set a particular batch size for emails. This\n> is a more reliable indicator to track the actual first patch.\n> \n> So, whenever the first patch is sent, $num_sent will become 1.\n> If we replace the condition to use threading from $message_num\n> to $num_sent=1, it will always be fulfilled irrespective of\n> whether the user edits the first patch or not, and thus threading\n> will turn on.\n> \n> This bug will not be triggered if --in-reply-to is not set,\n> because the first condition (not having an --in-reply-to) gets\n> fulfilled, so the script doesn't care what $message_num is there.\n> \n> Signed-off-by: Aditya Garg \n\nBTW, this patch is also my first successful trial with imap-send\nusing XOAUTH2 and Apple Mail as the sender ;)\n\n"},{"id":"518811","messageId":"xmqqwma7ug13.fsf@gitster.g","threadId":"63508","inReplyTo":"73234CC5-8712-4B7B-94BE-F643345677BD@live.com","subject":"Re: [PATCH] send-email: fix bug breaking shallow threading if the first patch is edited","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-23T22:19:04Z","receivedAt":"2025-05-23T22:19:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Aditya Garg writes:\n\n> So, whenever the first patch is sent, $num_sent will become 1.\n\nThe reverse is not always true, though.\n\n> \t# set up for the next message\n> +\t$num_sent++;\n> \tif ($thread) {\n> \t\tif ($message_was_sent &&\n> \t\t ($chain_reply_to || !defined $in_reply_to || length($in_reply_to) == 0 ||\n> -\t\t $message_num == 1)) {\n> +\t\t $num_sent == 1)) {\n\nThis sais \"enter this block if we have sent a message and one of\n(num_set is 1, or we are told to chain-reply-to, or we do not have\nin-reply-to) holds true\".\n\nBut is $num_set == 1 really limited to \"the first message\"? Given\nthat ...\n\n> \t\t\t$in_reply_to = $message_id;\n> \t\t\tif (length $references > 0) {\n> \t\t\t\t$references .= \"\\n $message_id\";\n> @@ -2060,7 +2061,6 @@ sub process_file {\n> \t\t$references = '';\n> \t}\n> \t$message_id = undef;\n> -\t$num_sent++;\n> \tif (defined $batch_size && $num_sent == $batch_size) {\n> \t\t$num_sent = 0;\n\n... the counter is reset when we send out the batch_size message\n(and we sleep in this block, which is outside the post-context of\nthis hunk). So when you send the first message of the next batch,\nyou'd do the same, no? By that time, we have in_reply_to set, but\nthat does not prevent from $num_sent, which was reset to 0 at the\nbatch boundary and then incremented to 1, to reenter the block in\nthe first hunk, no?\n\n> \t\t$smtp->quit if defined $smtp;\n"},{"id":"518815","messageId":"4dbb0dc7-52ef-4ffe-9215-de94fb448234@intel.com","threadId":"63508","inReplyTo":"73234CC5-8712-4B7B-94BE-F643345677BD@live.com","subject":"Re: [PATCH] send-email: fix bug breaking shallow threading if the first patch is edited","fromName":"Jacob Keller","fromEmail":"jacob.e.keller@intel.com","sentAt":"2025-05-23T23:37:53Z","receivedAt":"2025-05-23T23:38:43Z","isPatch":true,"sender":{"key":"jacob.e.keller@intel.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"\n\nOn 5/23/2025 8:36 AM, Aditya Garg wrote:\n> There is a bug in send-email that turns off shallow threading if\n> some special conditions are there. Those conditions are:\n> \n> 1. An --in-reply-to must be specified when sending the patch\n> 2. When asked for confirmation before sending the first patch, the\n> user must edit the patch (pressing e and enter).\n> \n> If these two conditions are fulfilled, the threading will turn off\n> and all subsequent messages will become as replies to the\n> Message-ID set in --in-reply-to, rather than becoming replies to\n> the first patch.\n> \n> The cause of this bug was very simple. There are many conditions\n> that determine whether threading should be done or not. The\n> relevant ones for this case are:\n> \n> 1. --in-reply-to is not defined\n> 2. $message_num is 1\n> \n> If ANY ONE of these is fulfilled, threading will occur. Now, in\n> our case, we have defined an --in-reply-to, so condition 1 is\n> not fulfilled, and thus is omitted out. The only condition that\n> can enable threading is $message_num being 1. As far as I\n> understand, this condition was based on the assumption that the\n> first message being send will have $message_num as 1, since in\n> case of shallow threads, we just set in-reply-to only for the\n> Message-ID of the first patch sent. But, in case we edit a patch,\n> its $message_num increases by one, and thus, our second condition\n> for threading is also not fulfilled, thus turning off threading.\n> \n\nWhy does editing a message change the message_num??? That feels like the\nreal bug to me..\n\n> Luckily, the script also keeps count of the number of messages\n> actually sent using the $num_sent variable. This was implemented\n> for people who have set a particular batch size for emails. This\n> is a more reliable indicator to track the actual first patch.\n> \n> So, whenever the first patch is sent, $num_sent will become 1.\n> If we replace the condition to use threading from $message_num\n> to $num_sent=1, it will always be fulfilled irrespective of\n> whether the user edits the first patch or not, and thus threading\n> will turn on.\n> \n\nJust from reading the commit message, this smells like a hack or\nworkaround to me.\n\nI don't fully understand the logic in place as-is, and I think using\nnum_sent is a bit of a weird way to resolve this.\n"},{"id":"518842","messageId":"20250524123911.1160-1-gargaditya08@live.com","threadId":"63508","inReplyTo":"73234CC5-8712-4B7B-94BE-F643345677BD@live.com","subject":"[PATCH v2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-24T12:39:43Z","receivedAt":"2025-05-24T12:39:47Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"In case a message is edited before it is sent, its message number gets\nincreased by 1, and so does its order in the message id. The cause of\nthis bug was that when a person attempts to edit the message, the whole\nsub process_file gets terminated, and the user is asked to edit the message.\nAfter necessary edits are done, the whole sub process_file is executed again.\nThe 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\nagain everytime a next message was sent in a thread, and thus we need to\nincrease the message number for that message. In case a user edits the message,\nthere is no check for the same and the new message gets treated as a subsequent\nmessage of a thread, therefore increasing its message number by one. This\nbreaks the shallow thread logic which relies on $message_num being 1 for the\nfirst message, and it gets changed in case the user edits the first message.\n\nSo, upon scanning the whole code, there are two significant variables at play\nhere. First is $message_num, responsible for the message number and second\nis $message_id_serial, responsible for showing the message number in the\nMessage-ID header. So, whenever we edit a message, lets just decrease them\nby 1, so that when the whole process to compose and send the message starts,\nthese variables increase by 1 again, thus get set to the original values for\nthat message.\n\nWe also are doing the same thing in case the user chooses to not send a message\nout of many messages in a thread. By doing so, we will simply decrease these\nvariables by 1 for further messages, thus ensuring the whole thread doesn't\nbreak.\n\nSigned-off-by: Aditya Garg \n---\n git-send-email.perl | 12 ++++++++++++\n 1 file changed, 12 insertions(+)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 55b7e00d29..b09251c4fc 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1639,8 +1639,20 @@ sub send_message {\n \t\t default => $ask_default);\n \t\tdie __(\"Send this email reply required\") unless defined $_;\n \t\tif (/^n/i) {\n+\t\t\t# If we are skipping a message, we should make sure that\n+\t\t\t# the next message is treated as the successor to the\n+\t\t\t# previously sent message, and not the skipped message.\n+\t\t\t$message_num--;\n+\t\t\t$message_id_serial--;\n \t\t\treturn 0;\n \t\t} elsif (/^e/i) {\n+\t\t\t# Since the same message will be sent again, we need to\n+\t\t\t# decrement the message number to the previous message.\n+\t\t\t# Otherwise, the edited message will be treated as a\n+\t\t\t# different message sent after the original non-edited\n+\t\t\t# message.\n+\t\t\t$message_num--;\n+\t\t\t$message_id_serial--;\n \t\t\treturn -1;\n \t\t} elsif (/^q/i) {\n \t\t\tcleanup_compose_files();\n-- \n2.49.0.windows.1\n\n"},{"id":"518861","messageId":"cover.1748192784.git.gargaditya08@live.com","threadId":"63508","inReplyTo":"20250524123911.1160-1-gargaditya08@live.com","subject":"[PATCH v3 0/2] send-email: fix threads breaking in case user edits emails and improvements to outlook ID fix.","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-25T17:12:16Z","receivedAt":"2025-05-25T17:12:21Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"Hi all,\n\nThis patch series fixes two minor issues with git-send-email.\n\nThe first patch fixes a bug that caused the message number to increase\nwhen a user edits an email. As a result of this bug, threads would\nbreak when a user edits an email.\n\nThe second patch improves the logging of the new message ID assigned by\nOutlook when a user edits an email.\n\nAditya Garg (2):\n send-email: fix bug resulting in increased message number if a message\n is edited\n send-email: show the new message id assigned by outlook in the logs\n\n git-send-email.perl | 16 +++++++++++++++-\n 1 file changed, 15 insertions(+), 1 deletion(-)\n\n-- \n2.43.0\n\n\n"},{"id":"518862","messageId":"259e20261e35908d5c7f6c36352f1f03be6da6ff.1748192784.git.gargaditya08@live.com","threadId":"63508","inReplyTo":"cover.1748192784.git.gargaditya08@live.com","subject":"[PATCH v3 1/2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-25T17:12:18Z","receivedAt":"2025-05-25T17:12:24Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"In case a message is edited before it is sent, its message number gets\nincreased by 1, and so does its order in the message id. The cause of\nthis bug was that when a person attempts to edit the message, the whole\nsub process_file gets terminated, and the user is asked to edit the message.\nAfter necessary edits are done, the whole sub process_file is executed again.\nThe 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\nagain everytime a next message was sent in a thread, and thus we need to\nincrease the message number for that message. In case a user edits the message,\nthere is no check for the same and the new message gets treated as a subsequent\nmessage of a thread, therefore increasing its message number by one. This\nbreaks the shallow thread logic which relies on $message_num being 1 for the\nfirst message, and it gets changed in case the user edits the first message.\n\nSo, upon scanning the whole code, there are two significant variables at play\nhere. First is $message_num, responsible for the message number and second\nis $message_id_serial, responsible for showing the message number in the\nMessage-ID header. So, whenever we edit a message, lets just decrease them\nby 1, so that when the whole process to compose and send the message starts,\nthese variables increase by 1 again, thus get set to the original values for\nthat message.\n\nWe also are doing the same thing in case the user chooses to not send a message\nout of many messages in a thread. By doing so, we will simply decrease these\nvariables by 1 for further messages, thus ensuring the whole thread doesn't\nbreak.\n\nSigned-off-by: Aditya Garg \n---\n git-send-email.perl | 12 ++++++++++++\n 1 file changed, 12 insertions(+)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 55b7e00d29..b09251c4fc 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1639,8 +1639,20 @@ sub send_message {\n \t\t default => $ask_default);\n \t\tdie __(\"Send this email reply required\") unless defined $_;\n \t\tif (/^n/i) {\n+\t\t\t# If we are skipping a message, we should make sure that\n+\t\t\t# the next message is treated as the successor to the\n+\t\t\t# previously sent message, and not the skipped message.\n+\t\t\t$message_num--;\n+\t\t\t$message_id_serial--;\n \t\t\treturn 0;\n \t\t} elsif (/^e/i) {\n+\t\t\t# Since the same message will be sent again, we need to\n+\t\t\t# decrement the message number to the previous message.\n+\t\t\t# Otherwise, the edited message will be treated as a\n+\t\t\t# different message sent after the original non-edited\n+\t\t\t# message.\n+\t\t\t$message_num--;\n+\t\t\t$message_id_serial--;\n \t\t\treturn -1;\n \t\t} elsif (/^q/i) {\n \t\t\tcleanup_compose_files();\n-- \n2.43.0\n\n\n"},{"id":"518863","messageId":"65619ac4d7e4891a6f0ea157c7d30b0d2072d3fa.1748192784.git.gargaditya08@live.com","threadId":"63508","inReplyTo":"cover.1748192784.git.gargaditya08@live.com","subject":"[PATCH v3 2/2] send-email: show the new message id assigned by outlook in the logs","fromName":"Aditya Garg","fromEmail":"gargaditya08@live.com","sentAt":"2025-05-25T17:12:20Z","receivedAt":"2025-05-25T17:12:26Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"body":"Whenever an email is sent, send-email shows a log at last, which\ncontains all the headers of the email that was send successfully.\nIn case outlook changes the Message-ID, a log for the same is\nshown to the user, but that change is not reflected when the log\ncontaining all the headers is displayed.\n\nThis patch fixes this by modifying the $header variable, which is\nresponsible for showing the logs at the end. Also, the log which\nstates that the Message-ID has been changed will now be shown only\nwhen smtp-debug is enabled, since the main log having all of the\nheaders is anyways displaying the new Message-ID.\n\nSigned-off-by: Aditya Garg \n---\n git-send-email.perl | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex b09251c4fc..e8019c40ba 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1776,7 +1776,9 @@ sub send_message {\n \t\tif (is_outlook($smtp_server)) {\n \t\t\tif ($smtp->message =~ /<([^>]+)>/) {\n \t\t\t\t$message_id = \"<$1>\";\n-\t\t\t\tprintf __(\"Outlook reassigned Message-ID to: %s\\n\"), $message_id;\n+\t\t\t\t# Replace the original Message-ID in $header with the new one\n+\t\t\t\t$header =~ s/^(Message-ID:\\s*).*\\n/${1}$message_id\\n/m;\n+\t\t\t\tprintf __(\"Outlook reassigned Message-ID to: %s\\n\"), $message_id if $smtp->debug;\n \t\t\t} else {\n \t\t\t\twarn __(\"Warning: Could not retrieve Message-ID from server response.\\n\");\n \t\t\t}\n-- \n2.43.0\n\n\n"},{"id":"518870","messageId":"7f5b2891-262f-48e7-9c29-7f3265abd07a@app.fastmail.com","threadId":"63508","inReplyTo":"259e20261e35908d5c7f6c36352f1f03be6da6ff.1748192784.git.gargaditya08@live.com","subject":"Re: [PATCH v3 1/2] send-email: fix bug resulting in increased message number if a message is edited","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-05-25T18:49:22Z","receivedAt":"2025-05-25T18:49:45Z","isPatch":true,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"Hi\n\n> send-email: fix bug resulting in increased message number if a message is edited\n\nI don’t understand what the bug is from the title. “Message number”\nsounds harmless. It breaks the threading? The summary/subject could\nsay that instead. Fix threading bug.\n\nOn 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\nIt feels like this part about increasing by one and if-editing gets\nrepeated 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\nHere’s the repetition.\n\nAlso 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\nWhich was incremented every time I did an edit with:\n\n send-email --suppress-cc=all --to= \\\n --confirm=always one two\n\nBut that turned out to be benign in my simple case since the next email\nused the correct In-Reply-To.\n\nSo 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\nThis feels like repetition again. You say that a variable is\nincremented 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\nIf I’m right in my assumption that this number is the `4` here:\n\n Message-ID: <20250525182426.41076-4-kristofferhaugsbakk@fastmail.com>\n\nThis was the first proposed email I got with “shallow thread” (all in\nreply to first):\n\n git send-email --suppress-cc=all --to= \\\n --thread --no-chain-reply-to --confirm=always one two three\n\nThen I edit all the messages. They still all manage to refer to the\nfirst message id in the thread.\n\nI still don’t understand what the bug is.\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"},{"id":"518947","messageId":"PN3PR01MB95973C8CEC731B43816AB38CB865A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM","threadId":"63508","inReplyTo":"7f5b2891-262f-48e7-9c29-7f3265abd07a@app.fastmail.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":"gargaditya08@live.com","sentAt":"2025-05-26T15:54:16Z","receivedAt":"2025-05-26T15:54:30Z","isPatch":true,"sender":{"key":"gargaditya08@live.com","avatar":"https://avatars.githubusercontent.com/u/85610623?v=4"},"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\nI have re-written the whole message again, but forgot to --in-reply-to this\nthread :(\n\nhttps://lore.kernel.org/git/cover.1748274404.git.gargaditya08@live.com/T/#t\nshould have the v4.\n\n"}]}