threads / patch / 59575

patchsend-email: export patch counters in validate environment

Subject: [PATCH] send-email: export patch counters in validate environment

## tl;dr

21 messages between Apr 11, 2023 and Apr 20, 2023. Diffs are folded; open one to read it.

replies: 20people: 3as markdown or json

Robin Jarry· Apr 11, 2023, 11:47 UTC · lore

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. A hook that wants to check some property of the whole series needs to know which patch is the final one.

Expose the current and total number of patches to the hook via the GIT_SENDEMAIL_PATCH_COUNTER and GIT_SENDEMAIL_PATCH_TOTAL environment variables so that both incremental and global validation is possible.

Sharing any other state between successive invocations of the validate hook must be done via external means. For example, by storing it in a GIT_DIR/SENDEMAIL_VALIDATE file.

Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Robin Jarry <robin@jarry.cc>
---

Notes:
    Follow up on:
    https://lore.kernel.org/git/9b8d6cc4-741a-5081-d5de-df0972efec37@gmail.com/
    
    As suggested by Phillip, this is a less intrusive change which allows
    validating whole series. Let me know what you think.

 Documentation/githooks.txt | 10 ++++++++++
 git-send-email.perl        |  7 +++++++
 2 files changed, 17 insertions(+)

Show changes to 2 files +17 −0

Documentation/githooks.txt, git-send-email.perl

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 62908602e7be..55f00e0f6f8c 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -600,6 +600,16 @@ 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.
 
+The following environment variables are set when executing the hook.
+
+`GIT_SENDEMAIL_PATCH_COUNTER`::
+	A 1-based counter incremented by one for every file.
+
+`GIT_SENDEMAIL_PATCH_TOTAL`::
+	The total number of files.
+
+These variables can be used to validate patch series.
+
 fsmonitor-watchman
 ~~~~~~~~~~~~~~~~~~
 
diff --git a/git-send-email.perl b/git-send-email.perl
index 07f2a0cbeaad..e962d5e15983 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -795,10 +795,17 @@ sub is_format_patch_arg {
 @files = handle_backup_files(@files);
 
 if ($validate) {
+	my $num = 1;
+	my $num_patches = @files;
 	foreach my $f (@files) {
 		unless (-p $f) {
+			$ENV{GIT_SENDEMAIL_PATCH_COUNTER} = "$num";
+			$ENV{GIT_SENDEMAIL_PATCH_TOTAL} = "$num_patches";
 			validate_patch($f, $target_xfer_encoding);
+			delete $ENV{GIT_SENDEMAIL_PATCH_COUNTER};
+			delete $ENV{GIT_SENDEMAIL_PATCH_TOTAL};
 		}
+		$num += 1;
 	}
 }

-- 
2.40.0

Phillip Wood· Apr 11, 2023, 13:23 UTC · re: Robin Jarry · lore

Re: [PATCH] send-email: export patch counters in validate environment

Hi Robin

On 11/04/2023 12:47, Robin Jarry wrote:

Show 25 quoted lines

> 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. A hook that
> wants to check some property of the whole series needs to know which
> patch is the final one.
> 
> Expose the current and total number of patches to the hook via the
> GIT_SENDEMAIL_PATCH_COUNTER and GIT_SENDEMAIL_PATCH_TOTAL environment
> variables so that both incremental and global validation is possible.
> 
> Sharing any other state between successive invocations of the validate
> hook must be done via external means. For example, by storing it in
> a GIT_DIR/SENDEMAIL_VALIDATE file.
> 
> Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
> Signed-off-by: Robin Jarry <robin@jarry.cc>
> ---
> 
> Notes:
>      Follow up on:
>      https://lore.kernel.org/git/9b8d6cc4-741a-5081-d5de-df0972efec37@gmail.com/
>      
>      As suggested by Phillip, this is a less intrusive change which allows
>      validating whole series. Let me know what you think.

This is certainly less intrusive, if it does what you need and is efficient enough for your needs then I'd be inclined to go with this approach.

Show 39 quoted lines

>   Documentation/githooks.txt | 10 ++++++++++
>   git-send-email.perl        |  7 +++++++
>   2 files changed, 17 insertions(+)
> 
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> index 62908602e7be..55f00e0f6f8c 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation/githooks.txt
> @@ -600,6 +600,16 @@ 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.
>   
> +The following environment variables are set when executing the hook.
> +
> +`GIT_SENDEMAIL_PATCH_COUNTER`::
> +	A 1-based counter incremented by one for every file.
> +
> +`GIT_SENDEMAIL_PATCH_TOTAL`::
> +	The total number of files.
> +
> +These variables can be used to validate patch series.
> +
>   fsmonitor-watchman
>   ~~~~~~~~~~~~~~~~~~
>   
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 07f2a0cbeaad..e962d5e15983 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -795,10 +795,17 @@ sub is_format_patch_arg {
>   @files = handle_backup_files(@files);
>   
>   if ($validate) {
> +	my $num = 1;
> +	my $num_patches = @files;
>   	foreach my $f (@files) {
>   		unless (-p $f) {
> +			$ENV{GIT_SENDEMAIL_PATCH_COUNTER} = "$num";
> +			$ENV{GIT_SENDEMAIL_PATCH_TOTAL} = "$num_patches";

We only need to set this once outside the loop

>   			validate_patch($f, $target_xfer_encoding);
> +			delete $ENV{GIT_SENDEMAIL_PATCH_COUNTER};
> +			delete $ENV{GIT_SENDEMAIL_PATCH_TOTAL};

Do we really need to clear these? Certainly not in each iteration of the loop I would think.

Best Wishes

Phillip

Show 5 quoted lines

>   		}
> +		$num += 1;
>   	}
>   }
>

Junio C Hamano· Apr 11, 2023, 16:28 UTC · re: Phillip Wood · lore

Re: [PATCH] send-email: export patch counters in validate environment

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 12 quoted lines

> Hi Robin
>
> On 11/04/2023 12:47, 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. A hook that
>> wants to check some property of the whole series needs to know which
>> patch is the final one.
>> Expose the current and total number of patches to the hook via the
>> GIT_SENDEMAIL_PATCH_COUNTER and GIT_SENDEMAIL_PATCH_TOTAL environment
>> variables so that both incremental and global validation is possible.

The above mentions "cover letter" and naturally the readers would wonder how it is treated. When we have 5-patch series with a separate cover letter, do we get TOTAL=6, COUNTER=1 for the cover, COUNTER=2 for [PATCH 1/5], and so on, or do we see TOTAL=5, COUNTER=0 for the cover, counter=1 for [PATCH 1/5], and so on?

The latter is certainly richer (with the former, the validator that wants to act differently on the cover has to somehow figure out if the invocation with COUNTER=1 is seeing the cover or the first patch). The usual and recommended workflow being "git format-patch -o outdir --cover-letter <range>" followed by "edit outdir/*" to proofread and edit the cover and the patches, followed by "git send-email outdir/*.patch", git-send-email has to guess before invoking the hook.

But it may be better than forcing the hook to guess, I dunno?

Whichever way we choose, we should

 * explain the choice in the proposed log message.  If we choose the
   "TOTAL is the number of patches and COUNTER=0 is used for the
   optional cover letter" interpretation, we should also explain
   that we cannot reliably do so and sometimes can guess wrong.  If
   we choose the "TOTAL is the number of input files and COUNTER
   just counts, regardless of the payload" interpretation, we should
   also explain that even though we hinted that a series with cover
   letter can be validated, it is a slight lie, because the hook has
   to guess if the series has cover and it can guess wrong.

 * document what TOTAL and COUNTER means.

Show 17 quoted lines

>> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
>> index 62908602e7be..55f00e0f6f8c 100644
>> --- a/Documentation/githooks.txt
>> +++ b/Documentation/githooks.txt
>> @@ -600,6 +600,16 @@ 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.
>>   +The following environment variables are set when executing the
>> hook.
>> +
>> +`GIT_SENDEMAIL_PATCH_COUNTER`::
>> +	A 1-based counter incremented by one for every file.
>> +
>> +`GIT_SENDEMAIL_PATCH_TOTAL`::
>> +	The total number of files.
>> +
>> +These variables can be used to validate patch series.

This may be sufficient documentation to imply we are not treating cover letter any differently, by not saying "patch" or "cover letter" but just saying "file". It may be more helpful to be a bit more explicit, though (e.g. "files" -> "input files", perhaps).

Show 15 quoted lines

>>   diff --git a/git-send-email.perl b/git-send-email.perl
>> index 07f2a0cbeaad..e962d5e15983 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -795,10 +795,17 @@ sub is_format_patch_arg {
>>   @files = handle_backup_files(@files);
>>     if ($validate) {
>> +	my $num = 1;
>> +	my $num_patches = @files;
>>   	foreach my $f (@files) {
>>   		unless (-p $f) {
>> +			$ENV{GIT_SENDEMAIL_PATCH_COUNTER} = "$num";
>> +			$ENV{GIT_SENDEMAIL_PATCH_TOTAL} = "$num_patches";
>
> We only need to set this once outside the loop

Indeed.

Show 6 quoted lines

>>   			validate_patch($f, $target_xfer_encoding);
>> +			delete $ENV{GIT_SENDEMAIL_PATCH_COUNTER};
>> +			delete $ENV{GIT_SENDEMAIL_PATCH_TOTAL};
>
> Do we really need to clear these? Certainly not in each iteration of
> the loop I would think.

If we set TOTAL outside, we should clear it outside. We have to set COUNTER inside, and we could clear it outside, but it probably is easier to see the correspondence of set/clear if it is done inside.

>>   		}
>> +		$num += 1;

When you have 3 files to send, and if the last one satisfies "-p", the hook will be told "You are called for 1/3" and then "2/3", and will never hear about "3/3", so in practice it will spool the first two and finish without getting a chance to flush what has been spooled. When you have 3 files to send, and if the first one satisfies "-p', the hook will be told "You are called for 2/3", but it is understandable if anybody is tempted to write a hook this way:

	if COUNTER==1:
		initialize the spool area
		record TOTAL there
	else:
		read TOTAL recorded in the spool area
		make sure TOTAL matches

	process [PATCH COUNTER/TOTAL] individually
	if COUNTER==TOTAL:
		process the series as a whole

and for such an invocation of "git send-email", the hook will try to process the second file without having its state fully initialzied because it never saw the first.

Would these be problems?  I dunno.

Thanks for working on the patch, and thanks for a careful review.

Robin Jarry· Apr 11, 2023, 17:13 UTC · re: Junio C Hamano · lore

Re: [PATCH] send-email: export patch counters in validate environment

Hi Junio,

Junio C Hamano, Apr 11, 2023 at 18:28:

Show 30 quoted lines

> The above mentions "cover letter" and naturally the readers would
> wonder how it is treated.  When we have 5-patch series with a
> separate cover letter, do we get TOTAL=6, COUNTER=1 for the cover,
> COUNTER=2 for [PATCH 1/5], and so on, or do we see TOTAL=5,
> COUNTER=0 for the cover, counter=1 for [PATCH 1/5], and so on?
>
> The latter is certainly richer (with the former, the validator that
> wants to act differently on the cover has to somehow figure out if
> the invocation with COUNTER=1 is seeing the cover or the first
> patch).  The usual and recommended workflow being "git format-patch
> -o outdir --cover-letter <range>" followed by "edit outdir/*" to
> proofread and edit the cover and the patches, followed by "git
> send-email outdir/*.patch", git-send-email has to guess before
> invoking the hook.
>
> But it may be better than forcing the hook to guess, I dunno?
>
> Whichever way we choose, we should
>
>  * explain the choice in the proposed log message.  If we choose the
>    "TOTAL is the number of patches and COUNTER=0 is used for the
>    optional cover letter" interpretation, we should also explain
>    that we cannot reliably do so and sometimes can guess wrong.  If
>    we choose the "TOTAL is the number of input files and COUNTER
>    just counts, regardless of the payload" interpretation, we should
>    also explain that even though we hinted that a series with cover
>    letter can be validated, it is a slight lie, because the hook has
>    to guess if the series has cover and it can guess wrong.
>
>  * document what TOTAL and COUNTER means.

It is easy enough to differentiate a cover letter from an actual patch with a simple shell test:

    if grep -q "^diff --git " "$1"; then
        # patch file
    else
        # cover letter
    fi

It is probably best to let git-send-email out of the picture. Since nothing prevents from sending multiple patch series at once, it may not be possible to determine the proper ordering of all these files. A dumb 1-based counter will be perfectly suitable.

I will add more details about these two variables, what they mean and how they should be used.

> This may be sufficient documentation to imply we are not treating
> cover letter any differently, by not saying "patch" or "cover
> letter" but just saying "file".  It may be more helpful to be a bit
> more explicit, though (e.g. "files" -> "input files", perhaps).

It makes sense to use the "files" terminology instead of "patches". I will update for v2.

Show 6 quoted lines

> > Do we really need to clear these? Certainly not in each iteration of
> > the loop I would think.
>
> If we set TOTAL outside, we should clear it outside.  We have to set
> COUNTER inside, and we could clear it outside, but it probably is
> easier to see the correspondence of set/clear if it is done inside.

Given the small cost of setting these variables in a perl script, it was my intention to have a clear correspondence between the set/clear operations.

Show 24 quoted lines

> When you have 3 files to send, and if the last one satisfies "-p",
> the hook will be told "You are called for 1/3" and then "2/3", and
> will never hear about "3/3", so in practice it will spool the first
> two and finish without getting a chance to flush what has been
> spooled.  When you have 3 files to send, and if the first one
> satisfies "-p', the hook will be told "You are called for 2/3", but
> it is understandable if anybody is tempted to write a hook this way:
>
> 	if COUNTER==1:
> 		initialize the spool area
> 		record TOTAL there
> 	else:
> 		read TOTAL recorded in the spool area
> 		make sure TOTAL matches
>
> 	process [PATCH COUNTER/TOTAL] individually
> 	if COUNTER==TOTAL:
> 		process the series as a whole
>
> and for such an invocation of "git send-email", the hook will try to
> process the second file without having its state fully initialzied
> because it never saw the first.
>
> Would these be problems?  I dunno.

I had thought of this. From perl docs:

    -p  File is a named pipe (FIFO), or Filehandle is a pipe.
    https://perldoc.perl.org/functions/-p

While there is very little chance that users will run git send-email on FIFOs, it is a possibility. Reference commit is:

    300913bd448de ("git-send-email: Accept fifos as well as files")
    https://github.com/git/git/commit/300913bd448de

I can run the loop twice to determine the count of non-FIFOs and adjust GIT_SENDEMAIL_FILE_TOTAL accordingly.

Thanks for the review.

PS: What would you think if I also added a sendemail-validate.sample
script in the templates folder? Should I add it in the same commit?

Junio C Hamano· Apr 11, 2023, 19:14 UTC · re: Robin Jarry · lore

Re: [PATCH] send-email: export patch counters in validate environment

"Robin Jarry" <robin@jarry.cc> writes:

> It is probably best to let git-send-email out of the picture. Since
> nothing prevents from sending multiple patch series at once, it may not
> be possible to determine the proper ordering of all these files. A dumb
> 1-based counter will be perfectly suitable.

As long as the design decision is clearly documented, I am more than fine to make it the user's problem ;-) It is a better design between the two, as the user knows better what their payload is.

> I can run the loop twice to determine the count of non-FIFOs and adjust
> GIT_SENDEMAIL_FILE_TOTAL accordingly.

It sounds like a reasonable way out.

Thanks.

Robin Jarry· Apr 11, 2023, 16:47 UTC · re: Phillip Wood · lore

Re: [PATCH] send-email: export patch counters in validate environment

Phillip Wood, Apr 11, 2023 at 15:23:

> This is certainly less intrusive, if it does what you need and is 
> efficient enough for your needs then I'd be inclined to go with this 
> approach.

Yes, that is perfectly suitable to validate series. The missing pieces of information (e.g. the place where all patches are spooled) can be either hard coded or stored in git config entries.

Show 13 quoted lines

> >   	foreach my $f (@files) {
> >   		unless (-p $f) {
> > +			$ENV{GIT_SENDEMAIL_PATCH_COUNTER} = "$num";
> > +			$ENV{GIT_SENDEMAIL_PATCH_TOTAL} = "$num_patches";
>
> We only need to set this once outside the loop
>
> >   			validate_patch($f, $target_xfer_encoding);
> > +			delete $ENV{GIT_SENDEMAIL_PATCH_COUNTER};
> > +			delete $ENV{GIT_SENDEMAIL_PATCH_TOTAL};
>
> Do we really need to clear these? Certainly not in each iteration of the 
> loop I would think.

I wanted to keep everything collocated. The time spent setting/unsetting these variables is completely negligible. I don't mind making this more streamlined in a v2.

Thanks for the review :)

Robin Jarry· Apr 12, 2023, 09:54 UTC · re: Robin Jarry · lore

[PATCH v2] send-email: export patch counters in validate environment

Sharing any other state between successive invocations of the validate hook must be done via external means. For example, by storing it in a git config sendemail.validateWorkdir entry.

Add a sample script with placeholder validations.

Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Robin Jarry <robin@jarry.cc>
---

Notes:
    v1 -> v2:
    
    * Added more details in documentation.
    * Exclude FIFOs from COUNT/TOTAL
    * Only set TOTAL once.
    * Only unset COUNT/TOTAL once.
    * Add sample hook script.

 Documentation/githooks.txt                 | 22 ++++++
 git-send-email.perl                        | 17 ++++-
 templates/hooks--sendemail-validate.sample | 84 ++++++++++++++++++++++
 3 files changed, 122 insertions(+), 1 deletion(-)
 create mode 100755 templates/hooks--sendemail-validate.sample

Show changes to 3 files +122 −1

Documentation/githooks.txt, git-send-email.perl, templates/hooks--sendemail-validate.sample

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 62908602e7be..c8e55b2613f5 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -600,6 +600,28 @@ 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.
 
+The following environment variables are set when executing the hook.
+
+`GIT_SENDEMAIL_FILE_COUNTER`::
+	A 1-based counter incremented by one for every file holding an e-mail
+	to be sent (excluding any FIFOs). This counter does not follow the
+	patch series counter scheme. It will always start at 1 and will end at
+	GIT_SENDEMAIL_FILE_TOTAL.
+
+`GIT_SENDEMAIL_FILE_TOTAL`::
+	The total number of files that will be sent (excluding any FIFOs). This
+	counter does not follow the patch series counter scheme. It will always
+	be equal to the number of files being sent, whether there is a cover
+	letter or not.
+
+These variables may for instance be used to validate patch series.
+
+The sample `sendemail-validate` hook that comes with Git checks that all sent
+patches (excluding the cover letter) can be applied on top of the upstream
+repository default branch without conflicts. Some placeholders are left for
+additional validation steps to be performed after all patches of a given series
+have been applied.
+
 fsmonitor-watchman
 ~~~~~~~~~~~~~~~~~~
 
diff --git a/git-send-email.perl b/git-send-email.perl
index 07f2a0cbeaad..497ec0354790 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -795,11 +795,26 @@ sub is_format_patch_arg {
 @files = handle_backup_files(@files);
 
 if ($validate) {
+	# FIFOs can only be read once, exclude them from validation.
+	my @real_files = ();
 	foreach my $f (@files) {
 		unless (-p $f) {
-			validate_patch($f, $target_xfer_encoding);
+			push(@real_files, $f);
 		}
 	}
+
+	# Run the loop once again to avoid gaps in the counter due to FIFO
+	# arguments provided by the user.
+	my $num = 1;
+	my $num_files = scalar @real_files;
+	$ENV{GIT_SENDEMAIL_FILE_TOTAL} = "$num_files";
+	foreach my $r (@real_files) {
+		$ENV{GIT_SENDEMAIL_FILE_COUNTER} = "$num";
+		validate_patch($r, $target_xfer_encoding);
+		$num += 1;
+	}
+	delete $ENV{GIT_SENDEMAIL_FILE_COUNTER};
+	delete $ENV{GIT_SENDEMAIL_FILE_TOTAL};
 }
 
 if (@files) {
diff --git a/templates/hooks--sendemail-validate.sample b/templates/hooks--sendemail-validate.sample
new file mode 100755
index 000000000000..c898ee3ab167
--- /dev/null
+++ b/templates/hooks--sendemail-validate.sample
@@ -0,0 +1,84 @@
+#!/bin/sh
+
+# An example hook script to validate a patch (and/or patch series) before
+# sending it via email.
+#
+# The hook should exit with non-zero status after issuing an appropriate
+# message if it wants to prevent the email(s) from being sent.
+#
+# To enable this hook, rename this file to "sendemail-validate".
+#
+# By default, it will only check that the patch(es) can be applied on top of
+# the default upstream branch without conflicts. Replace the XXX placeholders
+# with appropriate checks according to your needs.
+
+set -e
+
+validate_cover_letter()
+{
+	file="$1"
+	# XXX: Add appropriate checks here (e.g. spell checking).
+}
+
+validate_patch()
+{
+	file="$1"
+	# Ensure that the patch applies without conflicts to the latest
+	# upstream version.
+	git am -3 "$file" || die "failed to apply patch on upstream repo"
+	# XXX: Add appropriate checks here (e.g. checkpatch.pl).
+}
+
+validate_series()
+{
+	# XXX: Add appropriate checks here (e.g. quick build, etc.).
+}
+
+die()
+{
+	echo "sendemail-validate: error: $*" >&2
+	exit 1
+}
+
+get_work_dir()
+{
+	git config --get sendemail.validateWorkdir || {
+		# Initialize it to a temp dir, if unset.
+		git config --add sendemail.validateWorkdir "$(mktemp -d)"
+		git config --get sendemail.validateWorkdir
+	}
+}
+
+get_upstream_url()
+{
+	git config --get remote.origin.url ||
+		die "cannot get remote.origin.url"
+}
+
+clone_upstream()
+{
+	workdir="$1"
+	url="$(get_upstream_url)"
+	rm -rf -- "$workdir"
+	git clone --depth=1 "$url" "$workdir" ||
+		die "failed to clone upstream repository"
+}
+
+# main -------------------------------------------------------------------------
+
+workdir=$(get_work_dir)
+if [ "$GIT_SENDEMAIL_FILE_COUNTER" = 1 ]; then
+	clone_upstream "$workdir"
+fi
+cd "$workdir"
+export GIT_DIR="$workdir/.git"
+
+if grep -q "^diff --git " "$1"; then
+	validate_patch "$1"
+else
+	validate_cover_letter "$1"
+fi
+
+if [ "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL" ]; then
+	validate_series || die "patch series was rejected"
+fi

-- 
2.40.0

Junio C Hamano· Apr 12, 2023, 17:53 UTC · re: Robin Jarry · lore

Re: [PATCH v2] send-email: export patch counters in validate environment

Robin Jarry <robin@jarry.cc> writes:

>  if ($validate) {
> +	# FIFOs can only be read once, exclude them from validation.

It is very good to see this comment here, as it may not be obvious to everybody why we exclude them.

> +validate_cover_letter()
> +{

See Documentation/CodingGuidelines, look for "For shell scripts specifically" and follow what is in the section. There may be style violations of other kinds in the file.

Show 5 quoted lines

> +validate_patch()
> +{
> +	file="$1"
> +	# Ensure that the patch applies without conflicts to the latest
> +	# upstream version.

That comment is true only for the first one. The second patch needs to apply to the upstream plus the first patch, and so on.

Show 38 quoted lines

> +	git am -3 "$file" || die "failed to apply patch on upstream repo"
> +	# XXX: Add appropriate checks here (e.g. checkpatch.pl).
> +}
> +
> +validate_series()
> +{
> +	# XXX: Add appropriate checks here (e.g. quick build, etc.).
> +}
> +
> +die()
> +{
> +	echo "sendemail-validate: error: $*" >&2
> +	exit 1
> +}
> +
> +get_work_dir()
> +{
> +	git config --get sendemail.validateWorkdir || {
> +		# Initialize it to a temp dir, if unset.
> +		git config --add sendemail.validateWorkdir "$(mktemp -d)"
> +		git config --get sendemail.validateWorkdir
> +	}
> +}
> +
> +get_upstream_url()
> +{
> +	git config --get remote.origin.url ||
> +		die "cannot get remote.origin.url"
> +}
> +
> +clone_upstream()
> +{
> +	workdir="$1"
> +	url="$(get_upstream_url)"
> +	rm -rf -- "$workdir"
> +	git clone --depth=1 "$url" "$workdir" ||
> +		die "failed to clone upstream repository"
> +}

Style-wise, it is better to get rid of get_upstream_url and write the above more like

	workdir=$1 &&
	url=$(git config remote.originurl) &&
	rm -r -- "$workdir" &&
	git clone ... ||
	die "failed to ..."

and that would be less error prone (e.g. you will catch failure from "rm" yourself, instead of relying on "git clone" to catch it for you).

In any case, I would avoid network traffic and extra disk usage if I were showing an example for readers to follow, and would not recommend you to use "clone" here, even if it were a shallow one.

It would make much more sense to create a secondary worktree based on this repository, with its HEAD detached at the copy of the target branch (e.g. refs/remotes/origin/HEAD), and use that secondary worktree, as the necessary objects for "am -3" to fall back on are more likely to be found in such a setting, compared to a shallow clone that only can have the blobs at the tip.

> +
> +# main -------------------------------------------------------------------------

Show 6 quoted lines

> +workdir=$(get_work_dir)
> +if [ "$GIT_SENDEMAIL_FILE_COUNTER" = 1 ]; then
> +	clone_upstream "$workdir"
> +fi
> +cd "$workdir"
> +export GIT_DIR="$workdir/.git"

It is a good discipline to always set GIT_DIR and GIT_WORK_TREE as a pair. Working in a subdirectory of a working tree becomes awkward, because the presence of the former without the latter signals that your $(cwd) is at the top of the working tree.

But that is more or less moot, because I am suggesting not to use "git clone" to prepare the playground and instead use a secondary worktree that is attached to the same current repository, so GIT_DIR would be the same as the current one.

And because you are "cd"ing there anyway, it probably is much simpler to just

    unset GIT_DIR GIT_WORK_TREE

to let the repository discovery mechanism take care of it.

Show 9 quoted lines

> +if grep -q "^diff --git " "$1"; then
> +	validate_patch "$1"
> +else
> +	validate_cover_letter "$1"
> +fi
> +
> +if [ "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL" ]; then
> +	validate_series || die "patch series was rejected"
> +fi

It is uneven that validate_patch and validate_cover_letter are responsible for dying when problem is found, but validate_series is not and the caller is made responsible for that.

I would make the caller responsible for dying with message for all three by removing the calls to "die" or "exit" from the former two, if I were showing an example for readers to follow.

Overall, a very well crafted patch, even though little details and some design choices can be improved.

Thanks.

Robin Jarry· Apr 12, 2023, 18:33 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] send-email: export patch counters in validate environment

Hi Junio,

Junio C Hamano, Apr 12, 2023 at 19:53:

> See Documentation/CodingGuidelines, look for "For shell scripts
> specifically" and follow what is in the section.  There may be style
> violations of other kinds in the file.

I had missed that one. I'll have a look.

Show 5 quoted lines

> > +	# Ensure that the patch applies without conflicts to the latest
> > +	# upstream version.
>
> That comment is true only for the first one.  The second patch needs
> to apply to the upstream plus the first patch, and so on.

Will adjust this as well.

Show 12 quoted lines

> Style-wise, it is better to get rid of get_upstream_url and write
> the above more like
>
> 	workdir=$1 &&
> 	url=$(git config remote.originurl) &&
> 	rm -r -- "$workdir" &&
> 	git clone ... ||
> 	die "failed to ..."
>
> and that would be less error prone (e.g. you will catch failure from
> "rm" yourself, instead of relying on "git clone" to catch it for
> you).

I have added set -e at the beginning of the script, specifically to avoid the chained && commands which make the code hard to read. If any command returns/exits with a non-zero status which is not handled by an if or by a ||, the shell script will exit.

I can probably get rid of the explicit die statements because of this.

Show 10 quoted lines

> In any case, I would avoid network traffic and extra disk usage if I
> were showing an example for readers to follow, and would not
> recommend you to use "clone" here, even if it were a shallow one.
>
> It would make much more sense to create a secondary worktree based
> on this repository, with its HEAD detached at the copy of the target
> branch (e.g. refs/remotes/origin/HEAD), and use that secondary
> worktree, as the necessary objects for "am -3" to fall back on are
> more likely to be found in such a setting, compared to a shallow
> clone that only can have the blobs at the tip.

I have never used secondary worktrees. My original thinking was that the local repository may not be up to date compared to the upstream and running git fetch on the local repo seemed like a bad idea. Would there be a proper way to do this with secondary worktree?

There may not be an elegant generic solution here. $(git config remote.origin.url) may not even contain the proper upstream url...

Also, if I understand how worktrees function, applying patches in a detached HEAD will create blobs in the current git dir. These will eventually be garbage collected but I wonder if that could be a problem.

Show 16 quoted lines

> It is a good discipline to always set GIT_DIR and GIT_WORK_TREE as a
> pair.  Working in a subdirectory of a working tree becomes awkward,
> because the presence of the former without the latter signals that
> your $(cwd) is at the top of the working tree.
>
> But that is more or less moot, because I am suggesting not to use
> "git clone" to prepare the playground and instead use a secondary
> worktree that is attached to the same current repository, so GIT_DIR
> would be the same as the current one.
>
> And because you are "cd"ing there anyway, it probably is much
> simpler to just
>
>     unset GIT_DIR GIT_WORK_TREE
>
> to let the repository discovery mechanism take care of it.

Depending on whether I use a worktree or not, I will unset these variables.

Show 7 quoted lines

> It is uneven that validate_patch and validate_cover_letter are
> responsible for dying when problem is found, but validate_series is
> not and the caller is made responsible for that.
>
> I would make the caller responsible for dying with message for all
> three by removing the calls to "die" or "exit" from the former two,
> if I were showing an example for readers to follow.

Agreed, this is inconsistent. My original intent was to provide more explicit error messages but it is probably not necessary.

As explained above, `set -e` will force early exit if any command fails without being explicitly handled. I will remove die/exit calls.

> Overall, a very well crafted patch, even though little details and
> some design choices can be improved.

Thanks for the careful review!

Junio C Hamano· Apr 12, 2023, 20:37 UTC · re: Robin Jarry · lore

Re: [PATCH v2] send-email: export patch counters in validate environment

"Robin Jarry" <robin@jarry.cc> writes:

> Also, if I understand how worktrees function, applying patches in
> a detached HEAD will create blobs in the current git dir. These will
> eventually be garbage collected but I wonder if that could be a problem.

You are the user who just ran format-patch to prepare sending out the patches, and you are checking your patches. Wouldn't you have the blobs already anyways?

> As explained above, `set -e` will force early exit if any command fails
> without being explicitly handled. I will remove die/exit calls.

I'd rather not to see anybody go in that direction. "set -e" is a poor substitute for a properly designed error handling. Between

	set -e
	command A
	command B
	command C

and

	command A &&
	command B &&
	command C || die message

the former can only say "command B" failed because command B was run under some condition that it did not like, but that is too low level an error that is close to the implementation. As opposed to the latter that can talk about what it _means_ that any one of these three commands did not succeed in the end-user's terms.

Thanks.

Robin Jarry· Apr 12, 2023, 20:39 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] send-email: export patch counters in validate environment

Junio C Hamano, Apr 12, 2023 at 22:37:

> You are the user who just ran format-patch to prepare sending out
> the patches, and you are checking your patches.  Wouldn't you have
> the blobs already anyways?

But these will be new blobs since we are applying the patches from files into another detached branch.

Show 19 quoted lines

> I'd rather not to see anybody go in that direction.  "set -e" is a
> poor substitute for a properly designed error handling.  Between
>
> 	set -e
> 	command A
> 	command B
> 	command C
>
> and
>
> 	command A &&
> 	command B &&
> 	command C || die message
>
> the former can only say "command B" failed because command B was run
> under some condition that it did not like, but that is too low level
> an error that is close to the implementation.  As opposed to the
> latter that can talk about what it _means_ that any one of these
> three commands did not succeed in the end-user's terms.

Ok.

Junio C Hamano· Apr 12, 2023, 21:48 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] send-email: export patch counters in validate environment

Junio C Hamano <gitster@pobox.com> writes:

> Overall, a very well crafted patch, even though little details and
> some design choices can be improved.

One thing I forgot to mention. We probably want some test, perhaps adding something like the following to t9001 after we already test for --validate.

Thanks.

----------- >8 ---------------------- >8 ---------------------- >8 -----------
expected_file_counter_output () {
	total=$1
	count=0
	while test $count -ne $total
	do
		count=$((count + 1)) &&
		echo "$count/$total" || return
	done
}

test_expect_success $PREREQ '--validate hook allows counting of messages' '
	test_when_finished "rm my-hooks.log" &&
	test_config core.hooksPath "my-hooks" &&

	write_script my-hooks/sendemail-validate <<-\EOF &&
		num=$GIT_SENDEMAIL_FILE_COUNTER &&
		tot=$GIT_SENDEMAIL_FILE_TOTAL &&
		echo "$num/$tot" >>my-hooks.log || exit 1
	EOF

	>my-hooks.log &&
	expected_file_counter_output 1 >expect &&
	git send-email \
		--from="Example <from@example.com>" \
		--to=nobody@example.com \
		--smtp-server="$(pwd)/fake.sendmail" \
		--validate $patches &&
	test_cmp expect my-hooks.log
'

Robin Jarry· Apr 12, 2023, 21:45 UTC · re: Robin Jarry · lore

[PATCH v3] send-email: export patch counters in validate environment

Sharing any other state between successive invocations of the validate hook must be done via external means. For example, by storing it in a git config sendemail.validateWorktree entry.

Add a sample script with placeholders for validation.

Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Robin Jarry <robin@jarry.cc>
---

Notes:
    v2 -> v3:
    
    * Fixed style in sample script following Documentation/CodingGuidelines
    * Used git worktree instead of a shallow clone.
    * Removed set -e and added explicit error handling.
    * Reworded some comments.

 Documentation/githooks.txt                 | 22 +++++++
 git-send-email.perl                        | 17 +++++-
 templates/hooks--sendemail-validate.sample | 71 ++++++++++++++++++++++
 3 files changed, 109 insertions(+), 1 deletion(-)
 create mode 100755 templates/hooks--sendemail-validate.sample

Show changes to 3 files +109 −1

Documentation/githooks.txt, git-send-email.perl, templates/hooks--sendemail-validate.sample

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 62908602e7be..c8e55b2613f5 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -600,6 +600,28 @@ 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.
 
+The following environment variables are set when executing the hook.
+
+`GIT_SENDEMAIL_FILE_COUNTER`::
+	A 1-based counter incremented by one for every file holding an e-mail
+	to be sent (excluding any FIFOs). This counter does not follow the
+	patch series counter scheme. It will always start at 1 and will end at
+	GIT_SENDEMAIL_FILE_TOTAL.
+
+`GIT_SENDEMAIL_FILE_TOTAL`::
+	The total number of files that will be sent (excluding any FIFOs). This
+	counter does not follow the patch series counter scheme. It will always
+	be equal to the number of files being sent, whether there is a cover
+	letter or not.
+
+These variables may for instance be used to validate patch series.
+
+The sample `sendemail-validate` hook that comes with Git checks that all sent
+patches (excluding the cover letter) can be applied on top of the upstream
+repository default branch without conflicts. Some placeholders are left for
+additional validation steps to be performed after all patches of a given series
+have been applied.
+
 fsmonitor-watchman
 ~~~~~~~~~~~~~~~~~~
 
diff --git a/git-send-email.perl b/git-send-email.perl
index 07f2a0cbeaad..497ec0354790 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -795,11 +795,26 @@ sub is_format_patch_arg {
 @files = handle_backup_files(@files);
 
 if ($validate) {
+	# FIFOs can only be read once, exclude them from validation.
+	my @real_files = ();
 	foreach my $f (@files) {
 		unless (-p $f) {
-			validate_patch($f, $target_xfer_encoding);
+			push(@real_files, $f);
 		}
 	}
+
+	# Run the loop once again to avoid gaps in the counter due to FIFO
+	# arguments provided by the user.
+	my $num = 1;
+	my $num_files = scalar @real_files;
+	$ENV{GIT_SENDEMAIL_FILE_TOTAL} = "$num_files";
+	foreach my $r (@real_files) {
+		$ENV{GIT_SENDEMAIL_FILE_COUNTER} = "$num";
+		validate_patch($r, $target_xfer_encoding);
+		$num += 1;
+	}
+	delete $ENV{GIT_SENDEMAIL_FILE_COUNTER};
+	delete $ENV{GIT_SENDEMAIL_FILE_TOTAL};
 }
 
 if (@files) {
diff --git a/templates/hooks--sendemail-validate.sample b/templates/hooks--sendemail-validate.sample
new file mode 100755
index 000000000000..f6dbaa24ad57
--- /dev/null
+++ b/templates/hooks--sendemail-validate.sample
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+# An example hook script to validate a patch (and/or patch series) before
+# sending it via email.
+#
+# The hook should exit with non-zero status after issuing an appropriate
+# message if it wants to prevent the email(s) from being sent.
+#
+# To enable this hook, rename this file to "sendemail-validate".
+#
+# By default, it will only check that the patch(es) can be applied on top of
+# the default upstream branch without conflicts. Replace the XXX placeholders
+# with appropriate checks according to your needs.
+
+validate_cover_letter() {
+	file="$1"
+	# XXX: Add appropriate checks (e.g. spell checking).
+}
+
+validate_patch() {
+	file="$1"
+	# Ensure that the patch applies without conflicts.
+	git am -3 "$file" || return
+	# XXX: Add appropriate checks for this patch (e.g. checkpatch.pl).
+}
+
+validate_series() {
+	# XXX: Add appropriate checks for the whole series
+	# (e.g. quick build, coding style checks, etc.).
+}
+
+get_worktree() {
+	if ! git config --get sendemail.validateWorktree
+	then
+		# Initialize it to a temp dir, if unset.
+		worktree=$(mktemp --tmpdir -d sendemail-validate.XXXXXXX) &&
+		git config --add sendemail.validateWorktree "$worktree" &&
+		echo "$worktree"
+	fi
+}
+
+die() {
+	echo "sendemail-validate: error: $*" >&2
+	exit 1
+}
+
+# main -------------------------------------------------------------------------
+
+worktree=$(get_worktree) &&
+if test "$GIT_SENDEMAIL_FILE_COUNTER" = 1
+then
+	# ignore error if not a worktree
+	git worktree remove -f "$worktree" 2>/dev/null || :
+	echo "sendemail-validate: worktree $worktree"
+	git worktree add -fd --checkout "$worktree" refs/remotes/origin/HEAD
+fi || die "failed to prepare worktree for validation"
+
+unset GIT_DIR GIT_WORK_TREE
+cd "$worktree" &&
+
+if grep -q "^diff --git " "$1"
+then
+	validate_patch "$1"
+else
+	validate_cover_letter "$1"
+fi &&
+
+if test "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL"
+then
+	validate_series
+fi

-- 
2.40.0

Phillip Wood· Apr 13, 2023, 13:52 UTC · re: Robin Jarry · lore

Re: [PATCH v3] send-email: export patch counters in validate environment

Hi Robin

On 12/04/2023 22:45, Robin Jarry wrote:

Show 28 quoted lines

> 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. A hook that
> wants to check some property of the whole series needs to know which
> patch is the final one.
> 
> Expose the current and total number of patches to the hook via the
> GIT_SENDEMAIL_PATCH_COUNTER and GIT_SENDEMAIL_PATCH_TOTAL environment
> variables so that both incremental and global validation is possible.
> 
> Sharing any other state between successive invocations of the validate
> hook must be done via external means. For example, by storing it in
> a git config sendemail.validateWorktree entry.
> 
> Add a sample script with placeholders for validation.
> 
> Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
> Signed-off-by: Robin Jarry <robin@jarry.cc>
> ---
> 
> Notes:
>      v2 -> v3:
>      
>      * Fixed style in sample script following Documentation/CodingGuidelines
>      * Used git worktree instead of a shallow clone.
>      * Removed set -e and added explicit error handling.
>      * Reworded some comments.

I think the documentation and implementation look good, I've left a comment about the example hook below. As Junio has previously mentioned, it would be nice to have a test with this patch.

Show 59 quoted lines

> diff --git a/templates/hooks--sendemail-validate.sample b/templates/hooks--sendemail-validate.sample
> new file mode 100755
> index 000000000000..f6dbaa24ad57
> --- /dev/null
> +++ b/templates/hooks--sendemail-validate.sample
> @@ -0,0 +1,71 @@
> +#!/bin/sh
> +
> +# An example hook script to validate a patch (and/or patch series) before
> +# sending it via email.
> +#
> +# The hook should exit with non-zero status after issuing an appropriate
> +# message if it wants to prevent the email(s) from being sent.
> +#
> +# To enable this hook, rename this file to "sendemail-validate".
> +#
> +# By default, it will only check that the patch(es) can be applied on top of
> +# the default upstream branch without conflicts. Replace the XXX placeholders
> +# with appropriate checks according to your needs.
> +
> +validate_cover_letter() {
> +	file="$1"
> +	# XXX: Add appropriate checks (e.g. spell checking).
> +}
> +
> +validate_patch() {
> +	file="$1"
> +	# Ensure that the patch applies without conflicts.
> +	git am -3 "$file" || return
> +	# XXX: Add appropriate checks for this patch (e.g. checkpatch.pl).
> +}
> +
> +validate_series() {
> +	# XXX: Add appropriate checks for the whole series
> +	# (e.g. quick build, coding style checks, etc.).
> +}
> +
> +get_worktree() {
> +	if ! git config --get sendemail.validateWorktree
> +	then
> +		# Initialize it to a temp dir, if unset.
> +		worktree=$(mktemp --tmpdir -d sendemail-validate.XXXXXXX) &&
> +		git config --add sendemail.validateWorktree "$worktree" &&
> +		echo "$worktree"
> +	fi
> +}
> +
> +die() {
> +	echo "sendemail-validate: error: $*" >&2
> +	exit 1
> +}
> +
> +# main -------------------------------------------------------------------------
> +
> +worktree=$(get_worktree) &&
> +if test "$GIT_SENDEMAIL_FILE_COUNTER" = 1
> +then
> +	# ignore error if not a worktree
> +	git worktree remove -f "$worktree" 2>/dev/null || :

Now that you've got rid of "set -e" I don't think we need "|| :". I had expected that we'd always create a new worktree on the first patch in a series and remove it after processing the the last patch in the series, but this seems to leave it in place until the next time send-email is run or /tmp gets cleaned up. Also if I've understood it correctly the name is set the first time this hook is run, rather than generating a new name for each set of files that is validated.

Best Wishes

Phillip

Show 18 quoted lines

> +	echo "sendemail-validate: worktree $worktree"
> +	git worktree add -fd --checkout "$worktree" refs/remotes/origin/HEAD
> +fi || die "failed to prepare worktree for validation"
> +
> +unset GIT_DIR GIT_WORK_TREE
> +cd "$worktree" &&
> +
> +if grep -q "^diff --git " "$1"
> +then
> +	validate_patch "$1"
> +else
> +	validate_cover_letter "$1"
> +fi &&
> +
> +if test "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL"
> +then
> +	validate_series
> +fi

Robin Jarry· Apr 13, 2023, 14:01 UTC · re: Phillip Wood · lore

Re: [PATCH v3] send-email: export patch counters in validate environment

Hi Phillip,

Phillip Wood, Apr 13, 2023 at 15:52:

> I think the documentation and implementation look good, I've left a 
> comment about the example hook below. As Junio has previously mentioned, 
> it would be nice to have a test with this patch.

Yes, I only got Junio's email after sending v3 :)

The test case is ready. I was waiting for more comments before sending a v4.

> > +	git worktree remove -f "$worktree" 2>/dev/null || :
>
> Now that you've got rid of "set -e" I don't think we need "|| :".

Right.

Show 6 quoted lines

> I had expected that we'd always create a new worktree on the first
> patch in a series and remove it after processing the the last patch in
> the series, but this seems to leave it in place until the next time
> send-email is run or /tmp gets cleaned up. Also if I've understood it
> correctly the name is set the first time this hook is run, rather than
> generating a new name for each set of files that is validated.

I had thought that it would be useful to keep it in case the user wants to inspect and resolve issues. I you think it is a problem to leave it, I can deleted it after the last patch. In any case, if the user interrupts send-email before it has time to validate all patches, the worktree will be left in place.

Thanks for the review!

Phillip Wood· Apr 14, 2023, 12:58 UTC · re: Robin Jarry · lore

Re: [PATCH v3] send-email: export patch counters in validate environment

Hi Robin

On 13/04/2023 15:01, Robin Jarry wrote:

Show 11 quoted lines

> Hi Phillip,
> 
> Phillip Wood, Apr 13, 2023 at 15:52:
>> I think the documentation and implementation look good, I've left a
>> comment about the example hook below. As Junio has previously mentioned,
>> it would be nice to have a test with this patch.
> 
> Yes, I only got Junio's email after sending v3 :)
> 
> The test case is ready. I was waiting for more comments before sending
> a v4.

That's great, thank you for doing that.

Show 18 quoted lines

>>> +	git worktree remove -f "$worktree" 2>/dev/null || :
>>
>> Now that you've got rid of "set -e" I don't think we need "|| :".
> 
> Right.
> 
>> I had expected that we'd always create a new worktree on the first
>> patch in a series and remove it after processing the the last patch in
>> the series, but this seems to leave it in place until the next time
>> send-email is run or /tmp gets cleaned up. Also if I've understood it
>> correctly the name is set the first time this hook is run, rather than
>> generating a new name for each set of files that is validated.
> 
> I had thought that it would be useful to keep it in case the user wants
> to inspect and resolve issues. I you think it is a problem to leave it,
> I can deleted it after the last patch. In any case, if the user
> interrupts send-email before it has time to validate all patches, the
> worktree will be left in place.

I think leaving it in place if there is an error is fine, but it ought to clean up after itself if there isn't an error. More serious is that we use mktemp to create the worktree path the first time the hook is run and then just keep using that same path forever. It should be creating a new temporary directory with mktemp for each series to avoid clashes with existing entries in /tmp.

Best Wishes

Phillip

> Thanks for the review!

Robin Jarry· Apr 14, 2023, 15:28 UTC · re: Robin Jarry · lore

[PATCH v4] send-email: export patch counters in validate environment

Sharing any other state between successive invocations of the validate hook must be done via external means. For example, by storing it in a git config sendemail.validateWorktree entry.

Add a sample script with placeholder validations and update tests to check that the counters are properly exported.

Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Robin Jarry <robin@jarry.cc>
---

Notes:
    v3 -> v4:
    
    * Added test case.
    * Make sure to always cleanup the temp worktree.
    * Add configuration knobs to tweak the remote and ref on which to check
      if the patches apply without conflicts.

 Documentation/githooks.txt                 | 22 +++++++
 git-send-email.perl                        | 17 ++++-
 t/t9001-send-email.sh                      | 31 +++++++++
 templates/hooks--sendemail-validate.sample | 77 ++++++++++++++++++++++
 4 files changed, 146 insertions(+), 1 deletion(-)
 create mode 100755 templates/hooks--sendemail-validate.sample

Show changes to 4 files +146 −1

Documentation/githooks.txt, git-send-email.perl, t/t9001-send-email.sh, templates/hooks--sendemail-validate.sample

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 62908602e7be..c8e55b2613f5 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -600,6 +600,28 @@ 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.
 
+The following environment variables are set when executing the hook.
+
+`GIT_SENDEMAIL_FILE_COUNTER`::
+	A 1-based counter incremented by one for every file holding an e-mail
+	to be sent (excluding any FIFOs). This counter does not follow the
+	patch series counter scheme. It will always start at 1 and will end at
+	GIT_SENDEMAIL_FILE_TOTAL.
+
+`GIT_SENDEMAIL_FILE_TOTAL`::
+	The total number of files that will be sent (excluding any FIFOs). This
+	counter does not follow the patch series counter scheme. It will always
+	be equal to the number of files being sent, whether there is a cover
+	letter or not.
+
+These variables may for instance be used to validate patch series.
+
+The sample `sendemail-validate` hook that comes with Git checks that all sent
+patches (excluding the cover letter) can be applied on top of the upstream
+repository default branch without conflicts. Some placeholders are left for
+additional validation steps to be performed after all patches of a given series
+have been applied.
+
 fsmonitor-watchman
 ~~~~~~~~~~~~~~~~~~
 
diff --git a/git-send-email.perl b/git-send-email.perl
index 07f2a0cbeaad..497ec0354790 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -795,11 +795,26 @@ sub is_format_patch_arg {
 @files = handle_backup_files(@files);
 
 if ($validate) {
+	# FIFOs can only be read once, exclude them from validation.
+	my @real_files = ();
 	foreach my $f (@files) {
 		unless (-p $f) {
-			validate_patch($f, $target_xfer_encoding);
+			push(@real_files, $f);
 		}
 	}
+
+	# Run the loop once again to avoid gaps in the counter due to FIFO
+	# arguments provided by the user.
+	my $num = 1;
+	my $num_files = scalar @real_files;
+	$ENV{GIT_SENDEMAIL_FILE_TOTAL} = "$num_files";
+	foreach my $r (@real_files) {
+		$ENV{GIT_SENDEMAIL_FILE_COUNTER} = "$num";
+		validate_patch($r, $target_xfer_encoding);
+		$num += 1;
+	}
+	delete $ENV{GIT_SENDEMAIL_FILE_COUNTER};
+	delete $ENV{GIT_SENDEMAIL_FILE_TOTAL};
 }
 
 if (@files) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 323952a572d6..7c7625759883 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -2326,6 +2326,37 @@ test_expect_success $PREREQ 'invoke hook' '
 	)
 '
 
+expected_file_counter_output () {
+	total=$1
+	count=0
+	while test $count -ne $total
+	do
+		count=$((count + 1)) &&
+		echo "$count/$total" || return
+	done
+}
+
+test_expect_success $PREREQ '--validate hook allows counting of messages' '
+	test_when_finished "rm -rf my-hooks.log" &&
+	test_config core.hooksPath "my-hooks" &&
+	mkdir -p my-hooks &&
+
+	write_script my-hooks/sendemail-validate <<-\EOF &&
+		num=$GIT_SENDEMAIL_FILE_COUNTER &&
+		tot=$GIT_SENDEMAIL_FILE_TOTAL &&
+		echo "$num/$tot" >>my-hooks.log || exit 1
+	EOF
+
+	>my-hooks.log &&
+	expected_file_counter_output 4 >expect &&
+	git send-email \
+		--from="Example <from@example.com>" \
+		--to=nobody@example.com \
+		--smtp-server="$(pwd)/fake.sendmail" \
+		--validate -3 --cover-letter --force &&
+	test_cmp expect my-hooks.log
+'
+
 test_expect_success $PREREQ 'test that send-email works outside a repo' '
 	nongit git send-email \
 		--from="Example <nobody@example.com>" \
diff --git a/templates/hooks--sendemail-validate.sample b/templates/hooks--sendemail-validate.sample
new file mode 100755
index 000000000000..dcefcc1f992f
--- /dev/null
+++ b/templates/hooks--sendemail-validate.sample
@@ -0,0 +1,77 @@
+#!/bin/sh
+
+# An example hook script to validate a patch (and/or patch series) before
+# sending it via email.
+#
+# The hook should exit with non-zero status after issuing an appropriate
+# message if it wants to prevent the email(s) from being sent.
+#
+# To enable this hook, rename this file to "sendemail-validate".
+#
+# By default, it will only check that the patch(es) can be applied on top of
+# the default upstream branch without conflicts in a secondary worktree. After
+# validation (successful or not) of the last patch of a series, the worktree
+# will be deleted.
+#
+# The following config variables can be set to change the default remote and
+# remote ref that are used to apply the patches against:
+#
+#   sendemail.validateRemote (default: origin)
+#   sendemail.validateRemoteRef (default: HEAD)
+#
+# Replace the TODO placeholders with appropriate checks according to your
+# needs.
+
+validate_cover_letter() {
+	file="$1"
+	# TODO: Replace with appropriate checks (e.g. spell checking).
+	true
+}
+
+validate_patch() {
+	file="$1"
+	# Ensure that the patch applies without conflicts.
+	git am -3 "$file" || return
+	# TODO: Replace with appropriate checks for this patch
+	# (e.g. checkpatch.pl).
+	true
+}
+
+validate_series() {
+	# TODO: Replace with appropriate checks for the whole series
+	# (e.g. quick build, coding style checks, etc.).
+	true
+}
+
+# main -------------------------------------------------------------------------
+
+if test "$GIT_SENDEMAIL_FILE_COUNTER" = 1
+then
+	remote=$(git config --default origin --get sendemail.validateRemote) &&
+	ref=$(git config --default HEAD --get sendemail.validateRemoteRef) &&
+	worktree=$(mktemp --tmpdir -d sendemail-validate.XXXXXXX) &&
+	git worktree add -fd --checkout "$worktree" "refs/remotes/$remote/$ref" &&
+	git config --replace-all sendemail.validateWorktree "$worktree" &&
+else
+	worktree=$(git config --get sendemail.validateWorktree)
+fi || {
+	echo "sendemail-validate: error: failed to prepare worktree" >&2
+	exit 1
+}
+
+unset GIT_DIR GIT_WORK_TREE
+cd "$worktree" &&
+
+if grep -q "^diff --git " "$1"
+then
+	validate_patch "$1"
+else
+	validate_cover_letter "$1"
+fi &&
+
+if test "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL"
+then
+	git config --unset-all sendemail.validateWorktree &&
+	trap 'git worktree remove -ff "$worktree"' EXIT &&
+	validate_series
+fi

-- 
2.40.0

Robin Jarry· Apr 14, 2023, 15:50 UTC · re: Robin Jarry · lore

Re: [PATCH v4] send-email: export patch counters in validate environment

Robin Jarry, Apr 14, 2023 at 17:28:

> +	git config --replace-all sendemail.validateWorktree "$worktree" &&
> +else

Damn, I removed one echo line before sending and didn't test again... Sorry for the brain fart. I'll send a v5.

Robin Jarry· Apr 14, 2023, 15:52 UTC · re: Robin Jarry · lore

[PATCH v5] send-email: export patch counters in validate environment

Sharing any other state between successive invocations of the validate hook must be done via external means. For example, by storing it in a git config sendemail.validateWorktree entry.

Add a sample script with placeholder validations and update tests to check that the counters are properly exported.

Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: Robin Jarry <robin@jarry.cc>
---

Notes:
    v4 -> v5:
    
    * Fixed shell syntax error introduced by last minute change.
    
    v3 -> v4:
    
    * Added test case.
    * Make sure to always cleanup the temp worktree.
    * Add configuration knobs to tweak the remote and ref on which to check
      if the patches apply without conflicts.

 Documentation/githooks.txt                 | 22 +++++++
 git-send-email.perl                        | 17 ++++-
 t/t9001-send-email.sh                      | 31 +++++++++
 templates/hooks--sendemail-validate.sample | 77 ++++++++++++++++++++++
 4 files changed, 146 insertions(+), 1 deletion(-)
 create mode 100755 templates/hooks--sendemail-validate.sample

Show changes to 4 files +146 −1

Documentation/githooks.txt, git-send-email.perl, t/t9001-send-email.sh, templates/hooks--sendemail-validate.sample

diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 62908602e7be..c8e55b2613f5 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -600,6 +600,28 @@ 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.
 
+The following environment variables are set when executing the hook.
+
+`GIT_SENDEMAIL_FILE_COUNTER`::
+	A 1-based counter incremented by one for every file holding an e-mail
+	to be sent (excluding any FIFOs). This counter does not follow the
+	patch series counter scheme. It will always start at 1 and will end at
+	GIT_SENDEMAIL_FILE_TOTAL.
+
+`GIT_SENDEMAIL_FILE_TOTAL`::
+	The total number of files that will be sent (excluding any FIFOs). This
+	counter does not follow the patch series counter scheme. It will always
+	be equal to the number of files being sent, whether there is a cover
+	letter or not.
+
+These variables may for instance be used to validate patch series.
+
+The sample `sendemail-validate` hook that comes with Git checks that all sent
+patches (excluding the cover letter) can be applied on top of the upstream
+repository default branch without conflicts. Some placeholders are left for
+additional validation steps to be performed after all patches of a given series
+have been applied.
+
 fsmonitor-watchman
 ~~~~~~~~~~~~~~~~~~
 
diff --git a/git-send-email.perl b/git-send-email.perl
index 07f2a0cbeaad..497ec0354790 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -795,11 +795,26 @@ sub is_format_patch_arg {
 @files = handle_backup_files(@files);
 
 if ($validate) {
+	# FIFOs can only be read once, exclude them from validation.
+	my @real_files = ();
 	foreach my $f (@files) {
 		unless (-p $f) {
-			validate_patch($f, $target_xfer_encoding);
+			push(@real_files, $f);
 		}
 	}
+
+	# Run the loop once again to avoid gaps in the counter due to FIFO
+	# arguments provided by the user.
+	my $num = 1;
+	my $num_files = scalar @real_files;
+	$ENV{GIT_SENDEMAIL_FILE_TOTAL} = "$num_files";
+	foreach my $r (@real_files) {
+		$ENV{GIT_SENDEMAIL_FILE_COUNTER} = "$num";
+		validate_patch($r, $target_xfer_encoding);
+		$num += 1;
+	}
+	delete $ENV{GIT_SENDEMAIL_FILE_COUNTER};
+	delete $ENV{GIT_SENDEMAIL_FILE_TOTAL};
 }
 
 if (@files) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 323952a572d6..7c7625759883 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -2326,6 +2326,37 @@ test_expect_success $PREREQ 'invoke hook' '
 	)
 '
 
+expected_file_counter_output () {
+	total=$1
+	count=0
+	while test $count -ne $total
+	do
+		count=$((count + 1)) &&
+		echo "$count/$total" || return
+	done
+}
+
+test_expect_success $PREREQ '--validate hook allows counting of messages' '
+	test_when_finished "rm -rf my-hooks.log" &&
+	test_config core.hooksPath "my-hooks" &&
+	mkdir -p my-hooks &&
+
+	write_script my-hooks/sendemail-validate <<-\EOF &&
+		num=$GIT_SENDEMAIL_FILE_COUNTER &&
+		tot=$GIT_SENDEMAIL_FILE_TOTAL &&
+		echo "$num/$tot" >>my-hooks.log || exit 1
+	EOF
+
+	>my-hooks.log &&
+	expected_file_counter_output 4 >expect &&
+	git send-email \
+		--from="Example <from@example.com>" \
+		--to=nobody@example.com \
+		--smtp-server="$(pwd)/fake.sendmail" \
+		--validate -3 --cover-letter --force &&
+	test_cmp expect my-hooks.log
+'
+
 test_expect_success $PREREQ 'test that send-email works outside a repo' '
 	nongit git send-email \
 		--from="Example <nobody@example.com>" \
diff --git a/templates/hooks--sendemail-validate.sample b/templates/hooks--sendemail-validate.sample
new file mode 100755
index 000000000000..ad2f9a86473d
--- /dev/null
+++ b/templates/hooks--sendemail-validate.sample
@@ -0,0 +1,77 @@
+#!/bin/sh
+
+# An example hook script to validate a patch (and/or patch series) before
+# sending it via email.
+#
+# The hook should exit with non-zero status after issuing an appropriate
+# message if it wants to prevent the email(s) from being sent.
+#
+# To enable this hook, rename this file to "sendemail-validate".
+#
+# By default, it will only check that the patch(es) can be applied on top of
+# the default upstream branch without conflicts in a secondary worktree. After
+# validation (successful or not) of the last patch of a series, the worktree
+# will be deleted.
+#
+# The following config variables can be set to change the default remote and
+# remote ref that are used to apply the patches against:
+#
+#   sendemail.validateRemote (default: origin)
+#   sendemail.validateRemoteRef (default: HEAD)
+#
+# Replace the TODO placeholders with appropriate checks according to your
+# needs.
+
+validate_cover_letter() {
+	file="$1"
+	# TODO: Replace with appropriate checks (e.g. spell checking).
+	true
+}
+
+validate_patch() {
+	file="$1"
+	# Ensure that the patch applies without conflicts.
+	git am -3 "$file" || return
+	# TODO: Replace with appropriate checks for this patch
+	# (e.g. checkpatch.pl).
+	true
+}
+
+validate_series() {
+	# TODO: Replace with appropriate checks for the whole series
+	# (e.g. quick build, coding style checks, etc.).
+	true
+}
+
+# main -------------------------------------------------------------------------
+
+if test "$GIT_SENDEMAIL_FILE_COUNTER" = 1
+then
+	remote=$(git config --default origin --get sendemail.validateRemote) &&
+	ref=$(git config --default HEAD --get sendemail.validateRemoteRef) &&
+	worktree=$(mktemp --tmpdir -d sendemail-validate.XXXXXXX) &&
+	git worktree add -fd --checkout "$worktree" "refs/remotes/$remote/$ref" &&
+	git config --replace-all sendemail.validateWorktree "$worktree"
+else
+	worktree=$(git config --get sendemail.validateWorktree)
+fi || {
+	echo "sendemail-validate: error: failed to prepare worktree" >&2
+	exit 1
+}
+
+unset GIT_DIR GIT_WORK_TREE
+cd "$worktree" &&
+
+if grep -q "^diff --git " "$1"
+then
+	validate_patch "$1"
+else
+	validate_cover_letter "$1"
+fi &&
+
+if test "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL"
+then
+	git config --unset-all sendemail.validateWorktree &&
+	trap 'git worktree remove -ff "$worktree"' EXIT &&
+	validate_series
+fi

-- 
2.40.0

Robin Jarry· Apr 20, 2023, 19:16 UTC · re: Robin Jarry · lore

Re: [PATCH v5] send-email: export patch counters in validate environment

Robin Jarry, Apr 14, 2023 at 17:52:

Show 43 quoted lines

> diff --git a/templates/hooks--sendemail-validate.sample b/templates/hooks--sendemail-validate.sample
> new file mode 100755
> index 000000000000..ad2f9a86473d
> --- /dev/null
> +++ b/templates/hooks--sendemail-validate.sample
> @@ -0,0 +1,77 @@
> +#!/bin/sh
> +
> +# An example hook script to validate a patch (and/or patch series) before
> +# sending it via email.
> +#
> +# The hook should exit with non-zero status after issuing an appropriate
> +# message if it wants to prevent the email(s) from being sent.
> +#
> +# To enable this hook, rename this file to "sendemail-validate".
> +#
> +# By default, it will only check that the patch(es) can be applied on top of
> +# the default upstream branch without conflicts in a secondary worktree. After
> +# validation (successful or not) of the last patch of a series, the worktree
> +# will be deleted.
> +#
> +# The following config variables can be set to change the default remote and
> +# remote ref that are used to apply the patches against:
> +#
> +#   sendemail.validateRemote (default: origin)
> +#   sendemail.validateRemoteRef (default: HEAD)
> +#
> +# Replace the TODO placeholders with appropriate checks according to your
> +# needs.
> +
> +validate_cover_letter() {
> +	file="$1"
> +	# TODO: Replace with appropriate checks (e.g. spell checking).
> +	true
> +}
> +
> +validate_patch() {
> +	file="$1"
> +	# Ensure that the patch applies without conflicts.
> +	git am -3 "$file" || return
> +	# TODO: Replace with appropriate checks for this patch
> +	# (e.g. checkpatch.pl).
> +	true

Hey folks,

I had an idea after sending v5. Instead of leaving TODO placeholders, it would be nicer to introduce other git config sendemail.validate* options specific to this hook template so that users can directly use it without any modifications simply by setting options in their local clone:

    git config sendemail.validatePatchCmd 'tools/checkpatch.sh'
    git config sendemail.validateSeriesCmd 'make tests lint'

And reuse these commands if defined in the hook template.

What do you think?

Junio C Hamano· Apr 20, 2023, 19:25 UTC · re: Robin Jarry · lore

Re: [PATCH v5] send-email: export patch counters in validate environment

"Robin Jarry" <robin@jarry.cc> writes:

Show 9 quoted lines

> I had an idea after sending v5. Instead of leaving TODO placeholders, it
> would be nicer to introduce other git config sendemail.validate* options
> specific to this hook template so that users can directly use it without
> any modifications simply by setting options in their local clone:
>
>     git config sendemail.validatePatchCmd 'tools/checkpatch.sh'
>     git config sendemail.validateSeriesCmd 'make tests lint'
>
> And reuse these commands if defined in the hook template.

I do not think it is worth it, as they have to write the scripts or copy them from elsewhere, *and* need to make the configuration variables, *and* make the sample hook into a real one with such an approach.

After all, it is merely a sample. There is a value in keeping it simple so that users can learn what the structure should look like. Then users will come up with something much better suited for their own use case themselves.

Thanks.