git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Robin Jarry <robin@jarry.cc>
Cc: git@vger.kernel.org, Tim Culverhouse <tim@timculverhouse.com>,
	Nicolas Dichtel <nicolas.dichtel@6wind.com>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Phillip Wood <phillip.wood123@gmail.com>,
	Michael Strawbridge <michael.strawbridge@amd.com>
Subject: Re: [PATCH v2] hooks: add sendemail-validate-series
Date: Thu, 06 Apr 2023 10:56:30 +0200	[thread overview]
Message-ID: <230406.868rf5tkzs.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <20230405231305.96996-1-robin@jarry.cc>


On Thu, Apr 06 2023, Robin Jarry wrote:

> When sending patch series (with a cover-letter or not)
> sendemail-validate is called with every email/patch file independently
> from the others. When one of the patches depends on a previous one, 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,
> one per line. Patch file names that contain LF characters are *not*
> validated.
>
> Signed-off-by: Robin Jarry <robin@jarry.cc>
> ---
>
> Notes:
>     v1 -> v2:
>     
>     - Use `git hook run --to-stdin` with a temp file.
>     - Skip validation (with an explicit warning) for patch file names that
>       contain newline characters.
>     - Updated docs.

At first glance I thought this was a re-roll of the patches to include
the headers in the output, but I see that's a *different* series:
https://lore.kernel.org/git/5758ffc7-eb8c-4c16-d226-dd882cb2406b@amd.com/

But that was waiting on the --to-stdin I recently added, which you're
using here (good!).

But it seems to me that if that's integrated we'd end up with yet
another interface, or not? Is this proposing that we use this interface
instead for that use-case?

>  Documentation/git-send-email.txt |  1 +
>  Documentation/githooks.txt       | 19 +++++++++++++++++
>  git-send-email.perl              | 36 ++++++++++++++++++++++++++++++++
>  3 files changed, 56 insertions(+)
>
> 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 62908602e7be..0e8573c6c116 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation/githooks.txt
> @@ -600,6 +600,25 @@ 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.  For each e-mail to be sent,
> +it receives on standard input a line of the format:
> +
> +  <patch-file> LF
> +
> +where '<patch-file>' is an absolute path to a file that holds an e-mail to be
> +sent.  Any '<patch-file>' that contains a 'LF' character will *not* be fed to
> +the hook and an explicit warning will be printed instead.
> +
> +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 07f2a0cbeaad..b29050e14c06 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -800,6 +800,7 @@ sub is_format_patch_arg {
>  			validate_patch($f, $target_xfer_encoding);
>  		}
>  	}
> +	validate_patch_series(@files)
>  }
>  
>  if (@files) {
> @@ -2125,6 +2126,41 @@ sub validate_patch {
>  	return;
>  }
>  
> +sub validate_patch_series {
> +	my @files = @_;
> +
> +	unless ($repo) {
> +		return;
> +	}
> +	require File::Temp;
> +	my $tmp = File::Temp->new(
> +		TEMPLATE => "sendemail-series.XXXXXXXX",
> +		UNLINK => 1,
> +	);
> +	for my $fn (@files) {
> +		unless (-p $fn) {
> +			$fn = Cwd::abs_path($fn);

The code you mostly copy/pasted does "require Cwd", but can't we just
combine this with the existing function somehow?

> +			if ($fn =~ /\n/) {
> +				$fn =~ s/\n/'\\n'/g;
> +				printf STDERR __("warning: file name contains '\\n': %s. Skipping validation.\n"), $fn;
> +			} else {
> +				$tmp->print("$fn\n");
> +			}

Re feedback from others, I think *if* we keep this we should pass this
\0-delimited, that delimiter can be safley used with POSIX filenames.

> +		}
> +	}
> +	my $hook_name = "sendemail-validate-series";
> +	my @cmd = ("git", "hook", "run", "--ignore-missing",
> +		   "--to-stdin", $tmp->filename, $hook_name, "--");
> +	my $hook_error = system_or_msg(\@cmd, undef, "@cmd");
> +	if ($hook_error) {
> +		$hook_error = sprintf(
> +		    __("fatal: series rejected by %s hook\n%s\nwarning: no patches were sent\n"),
> +		    $hook_name, $hook_error);
> +		die $hook_error;
> +	}
> +	return;
> +}
> +
>  sub handle_backup {
>  	my ($last, $lastlen, $file, $known_suffix) = @_;
>  	my ($suffix, $skip);

Honestly, I don't really get the use-case. If your 02/N depends on 01/N
couldn't your hook just maintain its own state, e.g. in some file
created in the passed $GIT_DIR?

With the upcoming parallel hooks, I'm also skeptical of a an interface
that would preclude validating these in parallel.

I also don't understand the reason for the stdin interface. The
"git-send-email" program itself takes a <file|directory>, so concerns
about the files exceeding argument list seem out the window, i.e. we
could just pass the dir/files, and as we'd have the same limitations
here we should be able to pass the full set of files, no?

I.e. why not a sendemail-validate-all that just takes a dir or file(s)?

  reply	other threads:[~2023-04-06  9:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-02 18:56 [PATCH RESEND] hooks: add sendemail-validate-series Robin Jarry
2023-04-03  0:17 ` Eric Sunshine
2023-04-03 14:09 ` Phillip Wood
2023-04-03 14:32   ` Robin Jarry
2023-04-03 15:20     ` Phillip Wood
2023-04-03 15:42   ` Junio C Hamano
2023-04-03 17:25     ` Robin Jarry
2023-04-03 22:29   ` Robin Jarry
2023-04-03 22:52     ` Junio C Hamano
2023-04-03 22:59       ` Robin Jarry
2023-04-04 20:14         ` Junio C Hamano
2023-04-05  8:31           ` Robin Jarry
2023-04-05 21:49             ` Junio C Hamano
2023-04-05 23:13 ` [PATCH v2] " Robin Jarry
2023-04-06  8:56   ` Ævar Arnfjörð Bjarmason [this message]
2023-04-11  9:58     ` Phillip Wood
2023-04-11 10:39       ` Robin Jarry
2023-04-11 15:58       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=230406.868rf5tkzs.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=bagasdotme@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=michael.strawbridge@amd.com \
    --cc=nicolas.dichtel@6wind.com \
    --cc=phillip.wood123@gmail.com \
    --cc=robin@jarry.cc \
    --cc=sunshine@sunshineco.com \
    --cc=tim@timculverhouse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).