Refusing to use PRs

Posted Jan 12, 2026 22:46 UTC (Mon) by alx.manpages (subscriber, #145117)
In reply to: Refusing to use PRs by mathstuf
Parent article: Evans: A data model for Git (and other docs updates)

> > With that you keep track of who reviewed each patch.
>
> The problem is that not everyone has the entire list archive on hand at all times. If I hop onto a patch series in situ, I may be missing discussion history because it's not well-linked on lists. Personally, I prefer to reply to series 1's 00 patch with further series, but some maintainers don't like that because they toss the whole thread around. But that sounds like one can "spoil" a thread by replying with a (proposed) patch of their own which seems…unfortunate.

I also prefer like you having all v2,v3,... be replies to v1's 00 patch. As you said, that makes all the context available to a reader without much effort.

I just realized I haven't documented this in the contributing guidelines. I should document this now.

> > When the contributor sends a revision of the patch set, it will include those tags in the commits (if the reviewed commits haven't changed), which inform reviewers that certain patches have already been reviewed by some people.
>
> Will it? `b4` probably does it, but I've always ended up copying things manually. There's also no verification that the tags are actually truly sourced.

I do it manually. (Very) recently, I started appending a 'Message-ID:' tag right below each review tag, documenting the mail from which I took the tag. That makes sure I don't make mistakes, or at least that if I make mistakes one can easily check them. I don't expect frequent mistakes.

Another case is malicious tags. If one adds false tags, someone would likely realize and then bust the author. FWIW, I've seen invalid tags added in a patch generated by an LLM. We completely prohibit LLMs in the Linux man-pages project, and this served as yet another proof that the contribution was from an LLM, so I banned the user.