Skip to content

send-email: clarify missing subject error - #2375

Open
HaraldNordgren wants to merge 1 commit into
git:masterfrom
HaraldNordgren:fix/send-email-subject-error
Open

send-email: clarify missing subject error#2375
HaraldNordgren wants to merge 1 commit into
git:masterfrom
HaraldNordgren:fix/send-email-subject-error

Conversation

@HaraldNordgren

Copy link
Copy Markdown
Contributor

Explain the required Subject: prefix when a message file has no subject. Terminate the error with a newline so Perl does not append its internal source location.

Explain the required Subject: prefix when a message file has no subject.
Terminate the error with a newline so Perl does not append its internal
source location.

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
@HaraldNordgren

Copy link
Copy Markdown
Contributor Author

/submit

@gitgitgadget-git

Copy link
Copy Markdown

Submitted as pull.2375.git.git.1786267394375.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-2375/HaraldNordgren/fix/send-email-subject-error-v1

To fetch this version to local tag pr-git-2375/HaraldNordgren/fix/send-email-subject-error-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-2375/HaraldNordgren/fix/send-email-subject-error-v1

@gitgitgadget-git

Copy link
Copy Markdown

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Explain the required Subject: prefix when a message file has no subject.

Yes, get_patch_subject() is called from places where the caller
wants to determine whether the given file has at least one line that
begins with 'Subject:'.  In that case, the subroutine returns the
rest of that line; if it does not find any such line, it issues an
error message and dies.

As a side note, the check is curiously case-sensitive.  It is also
curious that the scanning does not stop at the first blank line that
terminates the email headers.  However, do not change this behavior
without studying the possible ramifications.  People have learned to
use various inputs that are not exactly what is output by 'git
format-patch', so rejecting a 'malformed' file simply because it
differs from typical 'git format-patch' output will break someone's
established workflow.

> Terminate the error with a newline so Perl does not append its internal
> source location.

Very nice spotting.  For an end-user facing script, the source
location is not useful.  The user is not debugging and fixing the
send-email script after all ;-).

> diff --git a/git-send-email.perl b/git-send-email.perl
> index bb8ddd1eef..4d76d53c49 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -863,7 +863,8 @@ sub get_patch_subject {
>  		return "GIT: $1\n";
>  	}
>  	close $fh;
> -	die sprintf(__("No subject line in %s?"), $fn);
> +	die sprintf(__("No subject line in %s. " .
> +		"The first line must start with \"Subject: \"\n"), $fn);
>  }

An input file to the 'git send-email' program is often the output
of 'git format-patch'.  Such a file begins with a UNIX 'From '
line, followed by email headers such as 'From:', 'Date:', and
'Subject:'.  The 'Subject:' line cannot be the first line of
the file in this case, yet it is a valid input.

The only condition that this subroutine flags as an error is when
the file lacks a subject line.  "No 'Subject:' line in '%s'\n" is a
clear message to display and is an improvement over the original.

However, the fact that the first line does not start with
"Subject:" is irrelevant to the basis of the subroutine's
decision to issue an error, I think.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant