On Sat, 6 Sept 2025 at 11:50, Konstantin Ryabitsev <[email protected]> wrote: > > The primary consumer of this are the CI systems, though, like those that plug > into patchwork
Yes, for a CI, it makes sense to try to have a fixed base, if such a base exists. But for that case, when a base exists and is published, why aren't those people and tools *actually* using git then? That gets rid of all the strangeness - and inefficiency - of trying to recreate it from emails. So I'd rather encourage people to have git branches that they expose, if CI is the main use case. For an example of how to do this right, look at what Al does. Recent patch series posted at https://lore.kernel.org/all/20250906090738.GA31600@ZenIV/ is a good example, and notice Al saying: Branches are in git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.path and git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.f_path resp.; individual patches in followups. in the cover letter. In other words: if the series was exported from a git tree and you have a base to use, why would it *EVER* be sane to then use 'b4 shazam' to get it? So I think what 'b4 shazam' _should_ be looking at is when Greg says "I like this a lot". I think it should aim for supporting maintainers that apply patch series as part of their workflow, not at CI tools that have the WRONG workflow. And yes, maybe fixing the CI tool workflow then involves having people who post patch series post the git branch too. I often find the git branches nicer for walking through some patch series anyway. But it goes both ways: for short series, since I'm in the MUA, just walking through five or six patches and replying to them is simpler, for longer series that do more involved things, I find doing a "git fetch" and then using git tooling to look at particular _parts_ of the series can be a lot more powerful. In fact, for long series that get reposted, just to not mess up my mailbox I would generally prefer to just see the git branch over some 50-email patch bomb. Maybe *that* would be a good addition for 'b4', where you can reply to just the cover letter and say "Ack for this series" or explicitly reply to particular patches - that might not even have been posted - by mentioning their commit IDs. That's my workflow much of the time, see for example https://lore.kernel.org/all/CAHk-=wgZEkSNKFe_=W=ocomtqiwq8j017mh+tur4av9gimp...@mail.gmail.com/ where I basically went through the series, and then replied to individual patches. I do like the "reply to individual patches" - even when I might actually have looked at them in git - just because then I can quote the part I reacted to. So I do think posting the patches makes sense as long as it's not some excessive patch-bomb, but at the same time I do know that a lot of patch series end up being of the type where possibly dozens of people get cc'd, but only on the one or two patches that are relevant to them. And then the git workflow *really* shines, because it gets you that context (and lots of people object to getting tens or hundreds of patches in email when only one or two are relevant to them). Linus
