On Tue, 2019-10-15 at 08:49 +0200, Geert Uytterhoeven wrote: > Hi Joe, Rehi Geert.
> On Mon, Oct 14, 2019 at 4:48 PM Joe Perches <j...@perches.com> wrote: > > On Mon, 2019-10-14 at 11:20 +0200, Geert Uytterhoeven wrote: [] > > > I gave your solution a try. > > > It only enables the reset-on-next-patch feature when using stdin. > > > Thanks to the printed subject, it's now obvious to which patch a > > > message applies to. > > > However, the output is significantly different than when passing > > > a split patch series. Can this be improved upon? > > > > > > Note that the only reason I'm using stdin is that I use formail to split > > > a bundle in individual patches. Once checkpatch supports bundles (or > > > mboxes) containing multiple patches, there's no longer a need for > > > using formail, and the reset-on-next-patch feature should be > > > enabled unconditionally. > > > > Using your collection of little tools idea, > > why not write a trivial script like: > > > > grep "^Subject:" $1 > > checkpatch.pl $1 > > > > and use that as the command line for formail > > instead of adding unnecessary complexity to > > checkpatch? > > That would be another possibility. > > But given more maintainers are starting to apply patchwork bundles (cfr. > the workflows discussions), it makes sense to make their lives easier. But given this particular change only works for stdin, then this patch splitting idea wouldn't generically work. > This is also useful for maintainers who save all patches to apply into a > single mbox, and run checkpatch+git-am on that. Which also wouldn't generally work for checkpatch <mbox> > Summarized: git-am handles multiple patches, checkpatch requires > splitting. I still think it's better to introduce YA script that disaggregates aggregated patches/emails and feeds each individual patch to checkpatch rather than making checkpatch learn how to disaggregate. Using "git mailsplit" as part of some additional script could work.
