Re: [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields

2 messages, 2 authors, 2016-06-16 · open the first message on its own page

Re: [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields

From: Junio C Hamano <hidden>
Date: 2016-06-16 02:19:49

Samuel GROOT [off-list ref] writes:
+if ($initial_reply_to && -f $initial_reply_to) {
+	my $error = validate_patch($initial_reply_to);
This call is wrong, isn't it?

You are not going to send out the message you are responding to (the
message may not even be a patch), and you do not want to die with an
error message that says "patch contains an overlong line".
+	die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
+		if $error;
+
+	open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
+	my $mail = Git::parse_email($fh);
+	close $fh;
	my $header = Git::parse_email_header($fh);

perhaps?
+	my $initial_sender = $sender || $repoauthor || $repocommitter || '';
+
+	my $prefix_re = "";
+	my $subject_re = $mail->{"subject"}[0];
+	if ($subject_re =~ /^[^Re:]/) {
+		$prefix_re = "Re: ";
+	}
+	$initial_subject = $prefix_re . $subject_re;
I am not sure what the significance of the fact that the subject
happens to begin with a letter other than 'R', 'e', or ':'.

Did you mean to do something like this instead?

	my $subject = $mail->{"subject"}[0];
	$subject =~ s/^(re:\s*)+//i; # strip "Re: Re: ..."
        $initial_subject = "Re: $subject";

instead?

By the way, this is a good example why your "unfold" implementation
in 4/6 is unwieldy for the caller.  Imagine a rather long subject
that is folded, i.e.

	To: Samuel
        Subject: Help! I am having a trouble running git-send-email
            correctly.
	Message-id: <...>

Re: [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields

From: Samuel GROOT <hidden>
Date: 2016-06-16 06:55:53

On 06/08/2016 08:23 PM, Junio C Hamano wrote:
Samuel GROOT [off-list ref] writes:
quoted
+if ($initial_reply_to && -f $initial_reply_to) {
+	my $error = validate_patch($initial_reply_to);
This call is wrong, isn't it?

You are not going to send out the message you are responding to (the
message may not even be a patch), and you do not want to die with an
error message that says "patch contains an overlong line".
We used to handle email files like patch files (with Cc:, To:, From:, 
... fields, a patch is almost an email, with some trailers).

But that `validate_patch` subroutine call is indeed useless here, I will 
remove it.
quoted
+	die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
+		if $error;
+
+	open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
+	my $mail = Git::parse_email($fh);
+	close $fh;
	my $header = Git::parse_email_header($fh);

perhaps?
Git::parse_email will be renamed into Git::parse_email_header in v5.
quoted
+	my $initial_sender = $sender || $repoauthor || $repocommitter || '';
+
+	my $prefix_re = "";
+	my $subject_re = $mail->{"subject"}[0];
+	if ($subject_re =~ /^[^Re:]/) {
+		$prefix_re = "Re: ";
+	}
+	$initial_subject = $prefix_re . $subject_re;
I am not sure what the significance of the fact that the subject
happens to begin with a letter other than 'R', 'e', or ':'.

Did you mean to do something like this instead?

	my $subject = $mail->{"subject"}[0];
	$subject =~ s/^(re:\s*)+//i; # strip "Re: Re: ..."
        $initial_subject = "Re: $subject";

instead?
That's way cleaner, thanks!
By the way, this is a good example why your "unfold" implementation
in 4/6 is unwieldy for the caller.  Imagine a rather long subject
that is folded, i.e.

	To: Samuel
        Subject: Help! I am having a trouble running git-send-email
            correctly.
	Message-id: <...>
It's a good point. What you suggested in 4/6 reply will be used in v5.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help