Hello, [...] >>> v2 and this iteration both have all messages set as replies to a >>> single message in the old thread. >>> >>> Please make sure in your future submissions: >>> >>> - [0/n] is a reply to [0/m] of the previous iteration. >>> >>> - [1/n], [2/n], ... and [n/n] are all replies to [0/n] of the same >>> iteration. >> >> OK. This means I need to submit with 'git send-email' in two steps, >> right? > > I do not think so. Find description of the "--in-reply-to" option > in the documentation, and read about interactions with "--thread" > and "--no-chain-reply-to" there? > > So for example when `--thread` and `--no-chain-reply-to` are specified, the > second and subsequent patches will be replies to the first one like in the > illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`: > > [PATCH 0/2] Here is what I did... > [PATCH 1/2] Clean up and tests > [PATCH 2/2] Implementation > [PATCH v2 0/3] Here is a reroll > [PATCH v2 1/3] Clean up > [PATCH v2 2/3] New tests > [PATCH v2 3/3] Implementation OK, so as a self-note; this is the default behavior (--thread and --no-chain-reply-to) and the thing I got wrong was that --in-reply-to should be set to the Message-ID of the previous revision's cover letter (in my recent submissions I had kept the message ID of the original cover letter instead). That's also explained in documentation/myfirstcontribution.adoc. I'll now send a v4 fixing the white space issue, making sure to --in-reply-to=$message-id-of-v3-cover-letter. -- Thanks, Maxim