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

[Eric Sunshine <sunshine@sunshineco.com>]

On Sun, Apr 2, 2023 at 3:19 PM Robin Jarry <robin@jarry.cc> wrote:
> 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.

> > 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.