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.
❦
$ 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)
