Re: [PATCH] hooks: add sendemail-validate-series

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Apr 3, 2023, 00:05 UTC
Message-ID: <CAPig+cS_+a+yu92+hKJ+Nvuvi4ymPOESaUgorYUAUGMAj9oZAg@mail.gmail.com>
In-Reply-To: <CRMHVBPXG6SW.2DL6RVNEMVERF@ringo>

On Sun, Apr 2, 2023 at 3:19 PM Robin Jarry <robin@jarry.cc> wrote:

Show 20 quoted lines

> Bagas Sanjaya, Apr 01, 2023 at 04:54:
> > In most cases, the patch series is generated by git-format-patch(1).
> > When the command is run, it will output:
> >
> > $ git format-patch -o /tmp --cover-letter --base=<base-commit> <base-commit>
> > /tmp/0000-cover-letter.patch
> > /tmp/0001-<patch-subject>.patch
> > /tmp/0002-<patch-subject>.patch
> > /tmp/0003-<patch-subject>.patch
> >
> > The output can be fed to the hook (as you write).
> >
> > But I think the hook should also take patch file arguments, for the
> > sake of completeness with sendemail-validate hook; that is:
> >
> > sendemail-validate-series <patch file>...
>
> I don't mind adding this but I am concerned with the maximum size of the
> command line arguments when sending large series. Standard input seems
> like a safer solution.

I share your concern, and don't see a good reason for complicating the implementation _and_ the API by feeding pathnames to the hook as both stdin and as arguments. Feeding them on stdin is the safer choice even if it makes the hook implementation a bit more clunky.

Show 7 quoted lines

> > Also, there should have a check that In-Reply-To must be the first
> > patch in the given series or the cover letter (if there is one).
>
> This is really non-trivial as it depends on the --[no-]chain-reply-to
> and --[no-]thread options. Also, the validation occurs before the
> message id headers are generated. I'd prefer trusting git-format-patch
> to order the patch files properly based on their file names.

Moreover, enforcing In-Reply-To: like that would almost certainly be undesirable. It may be policy on _this_ project to chain rerolls like that, but other projects have different policies, even to the point of prohibiting chaining.

Such In-Reply-To: enforcement is also well outside the scope of the patch under discussion, as well as being entirely orthogonal.

> > Anyway, rather than pinging by random people, I'd like to see [PATCH
> > RESEND], rebased on latest git.git tree, ideally with Junio Cc'ed.
>
> Will do. Thanks.

Generally speaking, once you've sent a patch or patch series, when you re-roll, you should _not_ rebase it onto Junio's latest "master" since doing so makes it harder for him to pick up the new version. In this case, your original patch didn't get picked up, so no harm done by rebasing it on "master", but it's good practice to avoid doing so unless there is a strong reason.