Re: [PATCH v2 0/2] Add strprefix() and fix a bug with it

[Bartosz Golaszewski]

On Thu, Nov 05, 2026 at 03:16:45PM +0100, Alejandro Colomar wrote:
> Hi Bart,
> 
> > Date: 2026-11-05 15:01:22+0100
> > From: Bartosz Golaszewski <brgl@xxxxxxxxxx>
> >
> [...]
> > 
> > I have no idea what causes it but I'm getting so many patches lately
> > that are subsequent iterations of a series sent with In-Reply-To: header
> > pointing to a previous thread.
> 
> I don't know what others do, but in my case it's a conscious manual
> action.  I use --in-reply-to in git-format-patch(1) to make all
> revisions of patch sets be descendants of the cover letter of v1.
> 
> We do this in the Linux man-pages, as it helps me keep track of all
> revisions of a patch set easily in mutt(1), without having to follow
> links or use more-complex tools like b4(1).
> 
> > Don't do this. Each new iteration must be a separate thread. Please use
> > b4 to manage patch series.
> 
> I won't use b4(1); I like bare git-send-email(1) and git-format-patch(1).
> But yeah, I can send them as separate threads, if that's the preference
> here.
> 

Yes. It's also the preference mentioned in the kernel documentation for
multi-patch series.

> Out of curiosity, what's the benefit of having separate threads?
> (Or the converse question: what's the main problem of using a single
>  thread?)

I may mark a thread in mutt as "done" for whatever reason and then all I
see is a reply under something I've already processed so I may as well
skip it. On the other hand: a new thread gets my full attention.

Such sub-threads also can confuse tools like b4 that maintainer use to
queue patches.

> They're morally a continuation of the previous threads, which is why it
> makes sense to me to have them as subthreads.
> 

That's what change-id is for in b4 tracking. That's also what the
changelog should contain: links to previous versions. All this is
already handled automatically by b4 which really is superior to manual
git send-email in every regard.

Thanks,
Bartosz