* [PATCH] send-email: don't duplicate Reply-to: in intro message
@ 2025-09-17 6:32 NeilBrown
2025-09-17 6:56 ` Eric Sunshine
2025-09-17 14:05 ` Junio C Hamano
0 siblings, 2 replies; 3+ messages in thread
From: NeilBrown @ 2025-09-17 6:32 UTC (permalink / raw)
To: git
From: NeilBrown <neil@brown.name>
If I run
git send-email --compose --reply-to 'ME <my@address.net>' .....
and edit the intro message, then it will get two copies of the Reply-To
field. gmail.com rejects such messages.
This happens because send-email reads the edited message examining the
headers. For recognised headers the content is extract to use in
constructing the final message and for possible inclusion in the patch
emails. Unrecognised headers are gathered (in @xh) to be passed though
uninterpreted.
Unfortunately "Reply-To" is not recognised in this process so it is
added to @xh as an uninterpreted header, but also generated from the
$reply_to variable in gen_header(), resulting in two copies
So:
Add parsing to the loop in pre_process_file() to recognise a Reply-to
header and to store the result in $reply_to. This means that the
intro message will not get a second header and also means that
any changes made to the Reply-To header during editing will be
incorporated in the $reply_to variable and so included in all the
generated email messages.
Signed-off-by: NeilBrown <neil@brown.name>
---
git-send-email.perl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 437f8ac46a85..e2248c223119 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1931,6 +1931,9 @@ sub pre_process_file {
$in_reply_to = $1;
}
}
+ elsif (/^Reply-To: (.*)/i) {
+ $reply_to = $1;
+ }
elsif (/^References: (.*)/i) {
if (!$initial_in_reply_to || $thread) {
$references = $1;
--
2.50.0.107.gf914562f5916.dirty
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] send-email: don't duplicate Reply-to: in intro message
2025-09-17 6:32 [PATCH] send-email: don't duplicate Reply-to: in intro message NeilBrown
@ 2025-09-17 6:56 ` Eric Sunshine
2025-09-17 14:05 ` Junio C Hamano
1 sibling, 0 replies; 3+ messages in thread
From: Eric Sunshine @ 2025-09-17 6:56 UTC (permalink / raw)
To: NeilBrown; +Cc: git
On Wed, Sep 17, 2025 at 2:33 AM NeilBrown <neilb@ownmail.net> wrote:
> If I run
>
> git send-email --compose --reply-to 'ME <my@address.net>' .....
>
> and edit the intro message, then it will get two copies of the Reply-To
> field. gmail.com rejects such messages.
>
> This happens because send-email reads the edited message examining the
> headers. For recognised headers the content is extract to use in
> constructing the final message and for possible inclusion in the patch
> emails. Unrecognised headers are gathered (in @xh) to be passed though
> uninterpreted.
s/extract/extracted/
s/though/through/
> Unfortunately "Reply-To" is not recognised in this process so it is
> added to @xh as an uninterpreted header, but also generated from the
> $reply_to variable in gen_header(), resulting in two copies
>
> So:
>
> Add parsing to the loop in pre_process_file() to recognise a Reply-to
> header and to store the result in $reply_to. This means that the
> intro message will not get a second header and also means that
> any changes made to the Reply-To header during editing will be
> incorporated in the $reply_to variable and so included in all the
> generated email messages.
>
> Signed-off-by: NeilBrown <neil@brown.name>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] send-email: don't duplicate Reply-to: in intro message
2025-09-17 6:32 [PATCH] send-email: don't duplicate Reply-to: in intro message NeilBrown
2025-09-17 6:56 ` Eric Sunshine
@ 2025-09-17 14:05 ` Junio C Hamano
1 sibling, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2025-09-17 14:05 UTC (permalink / raw)
To: NeilBrown; +Cc: git
NeilBrown <neilb@ownmail.net> writes:
> Add parsing to the loop in pre_process_file() to recognise a Reply-to
> header and to store the result in $reply_to. This means that the
> intro message will not get a second header and also means that
> any changes made to the Reply-To header during editing will be
> incorporated in the $reply_to variable and so included in all the
> generated email messages.
>
> Signed-off-by: NeilBrown <neil@brown.name>
> ---
> git-send-email.perl | 3 +++
> 1 file changed, 3 insertions(+)
Makes sense.
Just FYI for any future contributions, it is customary to mark the
second iteration as [PATCH v2] on the subject and to make the
message a direct reply (with "Reply-To") to the previous iteration,
to help people find how the patch evolved in the list archives like
https://lore.kernel.org/git/
Obviously no need to redo this patch only for that, but if you need
some other changes, sending v3 as a reply to the message I am
responding to would be a good thing to do.
Thanks.
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 437f8ac46a85..e2248c223119 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1931,6 +1931,9 @@ sub pre_process_file {
> $in_reply_to = $1;
> }
> }
> + elsif (/^Reply-To: (.*)/i) {
> + $reply_to = $1;
> + }
> elsif (/^References: (.*)/i) {
> if (!$initial_in_reply_to || $thread) {
> $references = $1;
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-09-17 14:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-17 6:32 [PATCH] send-email: don't duplicate Reply-to: in intro message NeilBrown
2025-09-17 6:56 ` Eric Sunshine
2025-09-17 14:05 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).