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

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

[Robin Jarry]

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(+)

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

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

[Phillip Wood]

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

>   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
>   		}
> +		$num += 1;
>   	}
>   }
>   

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

[Junio C Hamano]

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

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

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

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

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

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

[Robin Jarry]

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.

> >   	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 :)

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

[Robin Jarry]

Hi Junio,

Junio C Hamano, Apr 11, 2023 at 18:28:
> 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.

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

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

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

[Junio C Hamano]

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

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

[Robin Jarry]

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

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

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

[Junio C Hamano]

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.

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

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

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

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

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

[Robin Jarry]

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.

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

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

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

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

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

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

[Junio C Hamano]

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

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

[Robin Jarry]

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.

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

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

[Robin Jarry]

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.

 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

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

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

[Junio C Hamano]

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
'

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

[Phillip Wood]

Hi Robin

On 12/04/2023 22:45, 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.
> 
> 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.

> 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

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

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

[Robin Jarry]

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.

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

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

[Phillip Wood]

Hi Robin

On 13/04/2023 15:01, Robin Jarry wrote:
> 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.

>>> +	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!

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

[Robin Jarry]

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

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

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

[Robin Jarry]

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.

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

[Robin Jarry]

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

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

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

[Robin Jarry]

Robin Jarry, Apr 14, 2023 at 17:52:
> 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?

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

[Junio C Hamano]

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

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