Message ID | 20230103231133.64050-1-robin@jarry.cc (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | hooks: add sendemail-validate-series | expand |
Hi all, This is a gentle bump to see if that feature could be of interest for anyone. Thanks in advance.
Hey everyone - Bumping this one again and adding my name as someone who would greatly benefit from this feature.
Le 04/01/2023 à 00:11, Robin Jarry a écrit : > When sending patch series (with a cover-letter or not) > sendemail-validate is called with every email/patch file independently > from the others. When the one of the patches depend on a previous one to > apply, it may not be possible to use this hook in a meaningful way. > > Changing sendemail-validate to take all patches as arguments would break > backward compatibility. > > Add a new hook to allow validating patch series instead of patch by > patch. The patch files are provided in the hook script standard input. > > git hook run cannot be used since it closes the hook standard input. Run > the hook directly. > > Signed-off-by: Robin Jarry <robin@jarry.cc> Any news on this patch? Regards, Nicolas
On 1/4/23 06:11, Robin Jarry wrote: > +sendemail-validate-series > +~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +This hook is invoked by linkgit:git-send-email[1]. It allows performing > +validation on a complete patch series at once, instead of patch by patch with > +`sendemail-validate`. > + > +`sendemail-validate-series` takes no arguments, but for each e-mail to be sent > +it receives on standard input a line of the format: > + > + <patch-file> LF > + > +where `<patch-file>` is a name of a file that holds an e-mail to be sent, > + 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>... ``` 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). 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. Thanks.
Hi, 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. > 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. > 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.
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.
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt index 765b2df8530d..45113b928593 100644 --- a/Documentation/git-send-email.txt +++ b/Documentation/git-send-email.txt @@ -438,6 +438,7 @@ have been specified, in which case default to 'compose'. + -- * Invoke the sendemail-validate hook if present (see linkgit:githooks[5]). + * Invoke the sendemail-validate-series hook if present (see linkgit:githooks[5]). * Warn of patches that contain lines longer than 998 characters unless a suitable transfer encoding ('auto', 'base64', or 'quoted-printable') is used; diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt index a16e62bc8c8e..e2dc0b49eda5 100644 --- a/Documentation/githooks.txt +++ b/Documentation/githooks.txt @@ -588,6 +588,23 @@ the name of the file that holds the e-mail to be sent. Exiting with a non-zero status causes `git send-email` to abort before sending any e-mails. +sendemail-validate-series +~~~~~~~~~~~~~~~~~~~~~~~~~ + +This hook is invoked by linkgit:git-send-email[1]. It allows performing +validation on a complete patch series at once, instead of patch by patch with +`sendemail-validate`. + +`sendemail-validate-series` takes no arguments, but for each e-mail to be sent +it receives on standard input a line of the format: + + <patch-file> LF + +where `<patch-file>` is a name of a file that holds an e-mail to be sent, + +If the hook exits with non-zero status, `git send-email` will abort before +sending any e-mails. + fsmonitor-watchman ~~~~~~~~~~~~~~~~~~ diff --git a/git-send-email.perl b/git-send-email.perl index 5861e99a6eb2..30bce599b565 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -793,6 +793,7 @@ sub is_format_patch_arg { validate_patch($f, $target_xfer_encoding); } } + validate_patch_series(@files) } if (@files) { @@ -2118,6 +2119,47 @@ sub validate_patch { return; } +sub validate_patch_series { + my @files = @_; + + unless ($repo) { + return; + } + + my $hook_name = 'sendemail-validate-series'; + my $hooks_path = $repo->command_oneline('rev-parse', '--git-path', 'hooks'); + require File::Spec; + my $validate_hook = File::Spec->catfile($hooks_path, $hook_name); + my $hook_error; + unless (-x $validate_hook) { + return; + } + + # The hook needs a correct cwd and GIT_DIR. + require Cwd; + my $cwd_save = Cwd::getcwd(); + chdir($repo->wc_path() or $repo->repo_path()) or die("chdir: $!"); + local $ENV{"GIT_DIR"} = $repo->repo_path(); + # cannot use git hook run, it closes stdin before forking the hook + open(my $stdin, "|-", $validate_hook) or die("fork: $!"); + chdir($cwd_save) or die("chdir: $!"); + for my $fn (@files) { + unless (-p $fn) { + $fn = Cwd::abs_path($fn); + $stdin->print("$fn\n"); + } + } + close($stdin); # calls waitpid + if ($? & 0x7f) { + my $sig = $? & 0x7f; + die("fatal: hook $hook_name killed by signal $sig") + } elsif ($? >> 8) { + my $err = $? >> 8; + die("fatal: hook $hook_name rejected patch series (exit code $err)") + } + return; +} + sub handle_backup { my ($last, $lastlen, $file, $known_suffix) = @_; my ($suffix, $skip);
When sending patch series (with a cover-letter or not) sendemail-validate is called with every email/patch file independently from the others. When the one of the patches depend on a previous one to apply, it may not be possible to use this hook in a meaningful way. Changing sendemail-validate to take all patches as arguments would break backward compatibility. Add a new hook to allow validating patch series instead of patch by patch. The patch files are provided in the hook script standard input. git hook run cannot be used since it closes the hook standard input. Run the hook directly. Signed-off-by: Robin Jarry <robin@jarry.cc> --- Documentation/git-send-email.txt | 1 + Documentation/githooks.txt | 17 +++++++++++++ git-send-email.perl | 42 ++++++++++++++++++++++++++++++++ 3 files changed, 60 insertions(+)