Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 07f2a0cbeaad..bec4d0f4ab47 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -800,6 +800,7 @@ sub is_format_patch_arg {
>> validate_patch($f, $target_xfer_encoding);
>> }
>> }
>> + validate_patch_series(@files)
>
> This happens fairly early, before the user has had a chance to edit
> the patches and before we have added all the recipient and in-reply-to
> headers to the patch files. Would it be more useful to validate what
> will actually be sent?
I actually think the original intent was to catch errors in the part
of the file that can mechanically be created before letting the user
spend time on editing, without realizing that a later stage will be
rejected due to the auto-generated (e.g. came from a commit object)
stuff. I do not know why we need another hook to do pretty much the
same thing as the existing one (which could be taught to spool and
then the last round to validate, in addition to each step rejecting
incoming one as needed), but at least calling it there would be very
much in line with the existing one, I would say.
Thanks for a careful review.
