Re: [RFC] send-email: avoid duplicate In-Reply-To and References headers

2 messages, 2 authors, 2017-02-12 · open the first message on its own page

Re: [RFC] send-email: avoid duplicate In-Reply-To and References headers

From: Junio C Hamano <hidden>
Date: 2017-02-12 01:41:14

Eric Wong [off-list ref] writes:
When parsing an mbox, it is possible to get existing In-Reply-To
and References headers blindly appended into the headers of
message we generate.   This is probably the wrong thing to do
and we should prioritize what was given in the command-line,
cover letter, and previously-sent messages.

One example I've noticed in the wild was:

https://public-inbox.org/git/20161111124541.8216-17-vascomalmeida@sapo.pt/raw
---
 I'm not completely sure this is what Vasco was doing in that
 message, so it's an RFC for now...
I think it is sensibleto give priority to the --in-reply-to option
given from the command line over the in-file one.  I am not sure if
we want to drop references, though.  Wouldn't it make more sense to
just add what we got from the command line to what we read from the
file?  I dunno.
quoted hunk
 git-send-email.perl | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 068d60b3e6..5ab3d8585c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1543,7 +1543,13 @@ foreach my $t (@files) {
 			elsif (!/^Date:\s/i && /^[-A-Za-z]+:\s+\S/) {
 				push @xh, $_;
 			}
-
+			elsif (/^(?:References|In-Reply-To):/i) {
+				if (defined $initial_reply_to || $thread) {
+					warn
+"Ignoring $_ header in mbox body since it conflicts with\n
+--in-reply-to and --thread switches\n"
+				}
+			}
 		} else {
 			# In the traditional
 			# "send lots of email" format,

Re: [RFC] send-email: avoid duplicate In-Reply-To and References headers

From: Eric Wong <hidden>
Date: 2017-02-12 02:12:14

Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
When parsing an mbox, it is possible to get existing In-Reply-To
and References headers blindly appended into the headers of
message we generate.   This is probably the wrong thing to do
and we should prioritize what was given in the command-line,
cover letter, and previously-sent messages.

One example I've noticed in the wild was:

https://public-inbox.org/git/20161111124541.8216-17-vascomalmeida@sapo.pt/raw
---
 I'm not completely sure this is what Vasco was doing in that
 message, so it's an RFC for now...
I think it is sensibleto give priority to the --in-reply-to option
given from the command line over the in-file one.  I am not sure if
we want to drop references, though.  Wouldn't it make more sense to
just add what we got from the command line to what we read from the
file?  I dunno.
You're right, existing References in the bodies should probably
be prepended to current ones, as their order should be
oldest-to-newest.

I'll wait on comments a bit and work on a better version w/ tests
next week.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help