git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] send-email: Clear To: field for every mail
@ 2010-10-04  5:37 Viresh KUMAR
  2010-10-04  7:05 ` [PATCH] send-email: Don't leak To: headers between patches Stephen Boyd
  2010-10-04  7:09 ` [PATCH] send-email: Clear To: field for every mail Junio C Hamano
  0 siblings, 2 replies; 9+ messages in thread
From: Viresh KUMAR @ 2010-10-04  5:37 UTC (permalink / raw)
  To: git, gitster; +Cc: bebarino, Viresh Kumar

While sending multiple patches with a single git-send-email command,
To: field is not cleared after every mail. This patch clears To: field
after every patch sent.

Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Tested-by: Viresh Kumar <viresh.kumar@st.com>
---
 git-send-email.perl |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 1ccfb80..cf17704 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1150,6 +1150,7 @@ foreach my $t (@files) {
 	my $author_encoding;
 	my $has_content_type;
 	my $body_encoding;
+	@to = ();
 	@cc = ();
 	@xh = ();
 	my $input_format = undef;
-- 
1.7.2.3

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH] send-email: Don't leak To: headers between patches
  2010-10-04  5:37 [PATCH] send-email: Clear To: field for every mail Viresh KUMAR
@ 2010-10-04  7:05 ` Stephen Boyd
  2010-10-04  7:11   ` Junio C Hamano
  2010-10-04  7:15   ` Ævar Arnfjörð Bjarmason
  2010-10-04  7:09 ` [PATCH] send-email: Clear To: field for every mail Junio C Hamano
  1 sibling, 2 replies; 9+ messages in thread
From: Stephen Boyd @ 2010-10-04  7:05 UTC (permalink / raw)
  To: Viresh Kumar; +Cc: Junio C Hamano, git, Joe Perches

If the first patch in a series has a To: header in the file and the
second patch in the series doesn't the address from the first patch will
be part of the To: addresses in the second patch. Fix this by treating the
to list like the cc list. Have an initial to list come from the command
line, user input and config options. Then build up a to list from each
patch and concatenate the two together before sending the patch. Finally,
reset the list after sending each patch so the To: headers from a patch
don't get used for the next one.

Reported-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---

On 10/03/2010 10:37 PM, Viresh KUMAR wrote:
> While sending multiple patches with a single git-send-email command,
> To: field is not cleared after every mail. This patch clears To: field
> after every patch sent.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> Tested-by: Viresh Kumar <viresh.kumar@st.com>
> ---
>  git-send-email.perl |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 1ccfb80..cf17704 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1150,6 +1150,7 @@ foreach my $t (@files) {
>  	my $author_encoding;
>  	my $has_content_type;
>  	my $body_encoding;
> +	@to = ();
>  	@cc = ();
>  	@xh = ();
>  	my $input_format = undef;

Ah, I didn't think about this at all. Your patch doesn't look right though.
Consider a user adding a --to argument on the command line. The first patch
will be sent to the right place but the second one will be sent to nobody.
Right?

How about this instead? Based on sb/send-email-use-to-from-input. Junio,
looks like this would also fix a similar situation with the to_cmd in
next.

 git-send-email.perl   |   18 ++++++++++--------
 t/t9001-send-email.sh |   15 +++++++++++++++
 2 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index d6028ec..7f9eacd 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -138,7 +138,7 @@ sub unique_email_list(@);
 sub cleanup_compose_files();
 
 # Variables we fill in automatically, or via prompting:
-my (@to,$no_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
+my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
 	$initial_reply_to,$initial_subject,@files,
 	$author,$sender,$smtp_authpass,$annotate,$compose,$time);
 
@@ -213,7 +213,7 @@ my %config_settings = (
     "smtpuser" => \$smtp_authuser,
     "smtppass" => \$smtp_authpass,
 	"smtpdomain" => \$smtp_domain,
-    "to" => \@to,
+    "to" => \@initial_to,
     "cc" => \@initial_cc,
     "cccmd" => \$cc_cmd,
     "aliasfiletype" => \$aliasfiletype,
@@ -271,7 +271,7 @@ $SIG{INT}  = \&signal_handler;
 my $rc = GetOptions("sender|from=s" => \$sender,
                     "in-reply-to=s" => \$initial_reply_to,
 		    "subject=s" => \$initial_subject,
-		    "to=s" => \@to,
+		    "to=s" => \@initial_to,
 		    "no-to" => \$no_to,
 		    "cc=s" => \@initial_cc,
 		    "no-cc" => \$no_cc,
@@ -409,7 +409,7 @@ my ($repoauthor, $repocommitter);
 
 # Verify the user input
 
-foreach my $entry (@to) {
+foreach my $entry (@initial_to) {
 	die "Comma in --to entry: $entry'\n" unless $entry !~ m/,/;
 }
 
@@ -711,9 +711,9 @@ if (!defined $sender) {
 	$prompting++;
 }
 
-if (!@to) {
+if (!@initial_to) {
 	my $to = ask("Who should the emails be sent to? ");
-	push @to, parse_address_line($to) if defined $to; # sanitized/validated later
+	push @initial_to, parse_address_line($to) if defined $to; # sanitized/validated later
 	$prompting++;
 }
 
@@ -731,8 +731,8 @@ sub expand_one_alias {
 	return $aliases{$alias} ? expand_aliases(@{$aliases{$alias}}) : $alias;
 }
 
-@to = expand_aliases(@to);
-@to = (map { sanitize_address($_) } @to);
+@initial_to = expand_aliases(@initial_to);
+@initial_to = (map { sanitize_address($_) } @initial_to);
 @initial_cc = expand_aliases(@initial_cc);
 @bcclist = expand_aliases(@bcclist);
 
@@ -1136,6 +1136,7 @@ foreach my $t (@files) {
 	my $author_encoding;
 	my $has_content_type;
 	my $body_encoding;
+	@to = ();
 	@cc = ();
 	@xh = ();
 	my $input_format = undef;
@@ -1300,6 +1301,7 @@ foreach my $t (@files) {
 		($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1));
 	$needs_confirm = "inform" if ($needs_confirm && $confirm_unconfigured && @cc);
 
+	@to = (@initial_to, @to);
 	@cc = (@initial_cc, @cc);
 
 	my $message_was_sent = send_message();
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 294e31f..13d8d1a 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -971,6 +971,21 @@ test_expect_success $PREREQ 'patches To headers are appended to' '
 	grep "RCPT TO:<nobody@example.com>" stdout
 '
 
+test_expect_success $PREREQ 'To headers from files reset each patch' '
+	patch1=`git format-patch -1 --to="bodies@example.com"` &&
+	patch2=`git format-patch -1 --to="other@example.com" HEAD~` &&
+	test_when_finished "rm $patch1 && rm $patch2" &&
+	git send-email \
+		--dry-run \
+		--from="Example <nobody@example.com>" \
+		--to="nobody@example.com" \
+		--smtp-server relay.example.com \
+		$patch1 $patch2 >stdout &&
+	test $(grep -c "RCPT TO:<bodies@example.com>" stdout) = 1 &&
+	test $(grep -c "RCPT TO:<nobody@example.com>" stdout) = 2 &&
+	test $(grep -c "RCPT TO:<other@example.com>" stdout) = 1
+'
+
 test_expect_success $PREREQ 'setup expect' '
 cat >email-using-8bit <<EOF
 From fe6ecc66ece37198fe5db91fa2fc41d9f4fe5cc4 Mon Sep 17 00:00:00 2001
-- 
1.7.3.1.50.g1e633

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] send-email: Clear To: field for every mail
  2010-10-04  5:37 [PATCH] send-email: Clear To: field for every mail Viresh KUMAR
  2010-10-04  7:05 ` [PATCH] send-email: Don't leak To: headers between patches Stephen Boyd
@ 2010-10-04  7:09 ` Junio C Hamano
  2010-10-04  7:49   ` viresh kumar
  1 sibling, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2010-10-04  7:09 UTC (permalink / raw)
  To: Viresh KUMAR; +Cc: git, bebarino

Viresh KUMAR <viresh.kumar@st.com> writes:

> While sending multiple patches with a single git-send-email command,
> To: field is not cleared after every mail. This patch clears To: field
> after every patch sent.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> Tested-by: Viresh Kumar <viresh.kumar@st.com>
> ---

Heh, are people who send patches with only S-o-b by your definition not
testing their patches at all ;-)?  As far as I can tell, your patch
applied to 'next' will break t9001 rather badly.

I agree there is a bug that you are trying to address in the series by
Stephen that keeps adding To: address that is read from an earlier output
of format-patch created with its --to option, but I do not think this is a
right fix.  Have you tested sending a series with a plain format-patch
output without extraneous To:, Cc: and such headers?

A normal send-email session takes the recipient address from either --to
or interactively upfront, and then use those addresses kept in @to
variable in the loop, repeatedly.  I do not see anything in your patch to
avoid losing these addresses.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] send-email: Don't leak To: headers between patches
  2010-10-04  7:05 ` [PATCH] send-email: Don't leak To: headers between patches Stephen Boyd
@ 2010-10-04  7:11   ` Junio C Hamano
  2010-10-04  7:15   ` Ævar Arnfjörð Bjarmason
  1 sibling, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2010-10-04  7:11 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: Viresh Kumar, git, Joe Perches

Stephen Boyd <bebarino@gmail.com> writes:

> Ah, I didn't think about this at all. Your patch doesn't look right though.
> Consider a user adding a --to argument on the command line. The first patch
> will be sent to the right place but the second one will be sent to nobody.
> Right?
>
> How about this instead? Based on sb/send-email-use-to-from-input. Junio,
> looks like this would also fix a similar situation with the to_cmd in
> next.

Yeah, I haven't applied nor run it, but your fix looks correct.  Thanks.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] send-email: Don't leak To: headers between patches
  2010-10-04  7:05 ` [PATCH] send-email: Don't leak To: headers between patches Stephen Boyd
  2010-10-04  7:11   ` Junio C Hamano
@ 2010-10-04  7:15   ` Ævar Arnfjörð Bjarmason
  2010-10-04  7:25     ` Ævar Arnfjörð Bjarmason
  1 sibling, 1 reply; 9+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2010-10-04  7:15 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: Viresh Kumar, Junio C Hamano, git, Joe Perches

On Mon, Oct 4, 2010 at 07:05, Stephen Boyd <bebarino@gmail.com> wrote:
> If the first patch in a series has a To: header in the file and the
> second patch in the series doesn't the address from the first patch will
> be part of the To: addresses in the second patch. Fix this by treating the
> to list like the cc list. Have an initial to list come from the command
> line, user input and config options. Then build up a to list from each
> patch and concatenate the two together before sending the patch. Finally,
> reset the list after sending each patch so the To: headers from a patch
> don't get used for the next one.

Couldn't this whole thing be done by:

>  # Variables we fill in automatically, or via prompting:
> -my (@to,$no_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
> +my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,

Changing this to an "our" variable instead of a "my".

>        my $body_encoding;
> +       @to = ();

Then doing:

    local @to = @to;

> +       @to = (@initial_to, @to);
>        @cc = (@initial_cc, @cc);

And keeping this as it is, and should the @cc addresses by accumulated
across patches, but not the @to addresses?

> +test_expect_success $PREREQ 'To headers from files reset each patch' '
> +       patch1=`git format-patch -1 --to="bodies@example.com"` &&
> +       patch2=`git format-patch -1 --to="other@example.com" HEAD~` &&
> +       test_when_finished "rm $patch1 && rm $patch2" &&
> +       git send-email \
> +               --dry-run \
> +               --from="Example <nobody@example.com>" \
> +               --to="nobody@example.com" \
> +               --smtp-server relay.example.com \
> +               $patch1 $patch2 >stdout &&
> +       test $(grep -c "RCPT TO:<bodies@example.com>" stdout) = 1 &&
> +       test $(grep -c "RCPT TO:<nobody@example.com>" stdout) = 2 &&
> +       test $(grep -c "RCPT TO:<other@example.com>" stdout) = 1
> +'
> +

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] send-email: Don't leak To: headers between patches
  2010-10-04  7:15   ` Ævar Arnfjörð Bjarmason
@ 2010-10-04  7:25     ` Ævar Arnfjörð Bjarmason
  2010-10-04  8:00       ` Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2010-10-04  7:25 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: Viresh Kumar, Junio C Hamano, git, Joe Perches

On Mon, Oct 4, 2010 at 07:15, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Mon, Oct 4, 2010 at 07:05, Stephen Boyd <bebarino@gmail.com> wrote:
>> If the first patch in a series has a To: header in the file and the
>> second patch in the series doesn't the address from the first patch will
>> be part of the To: addresses in the second patch. Fix this by treating the
>> to list like the cc list. Have an initial to list come from the command
>> line, user input and config options. Then build up a to list from each
>> patch and concatenate the two together before sending the patch. Finally,
>> reset the list after sending each patch so the To: headers from a patch
>> don't get used for the next one.
>
> Couldn't this whole thing be done by:
>
>>  # Variables we fill in automatically, or via prompting:
>> -my (@to,$no_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
>> +my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
>
> Changing this to an "our" variable instead of a "my".
>
>>        my $body_encoding;
>> +       @to = ();
>
> Then doing:
>
>    local @to = @to;
>
>> +       @to = (@initial_to, @to);
>>        @cc = (@initial_cc, @cc);

Small brainfart, you don't have to change it to an "our" and use
"local", you can just use "my" in that for-loop:

    $ perl -E 'my @a = qw(a b); { my @a = (@a, "c"); say "@a" } say "@a"'
    a b c
    a b

That's a much better solution IMO than the C-like usage of two
variables. Lexical shadowing is exactly for this sort of thing.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] send-email: Clear To: field for every mail
  2010-10-04  7:09 ` [PATCH] send-email: Clear To: field for every mail Junio C Hamano
@ 2010-10-04  7:49   ` viresh kumar
  0 siblings, 0 replies; 9+ messages in thread
From: viresh kumar @ 2010-10-04  7:49 UTC (permalink / raw)
  To: Junio C Hamano, bebarino@gmail.com; +Cc: git@vger.kernel.org

On 10/04/2010 12:39 PM, Junio C Hamano wrote:
> Heh, are people who send patches with only S-o-b by your definition not
> testing their patches at all ;-)?  As far as I can tell, your patch
> applied to 'next' will break t9001 rather badly.
> 
> I agree there is a bug that you are trying to address in the series by
> Stephen that keeps adding To: address that is read from an earlier output
> of format-patch created with its --to option, but I do not think this is a
> right fix.  Have you tested sending a series with a plain format-patch
> output without extraneous To:, Cc: and such headers?
> 
> A normal send-email session takes the recipient address from either --to
> or interactively upfront, and then use those addresses kept in @to
> variable in the loop, repeatedly.  I do not see anything in your patch to
> avoid losing these addresses.

Junio, Stephan,

Ya! my patch wasn't good enough. I just tried to solve it the way it was done
for cc.

-- 
viresh

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] send-email: Don't leak To: headers between patches
  2010-10-04  7:25     ` Ævar Arnfjörð Bjarmason
@ 2010-10-04  8:00       ` Junio C Hamano
  2010-10-04 18:55         ` Joe Perches
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2010-10-04  8:00 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Stephen Boyd, Viresh Kumar, git, Joe Perches

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> That's a much better solution IMO than the C-like usage of two
> variables. Lexical shadowing is exactly for this sort of thing.

Lexical scoping, yes, shadowing a variable of the same name in the outer
scope, no.  The latter is a readability nightmare in the longer term.

IOW, I would prefer to keep @initial_to and @initial_cc as "these apply
globally to the whole command invocation", copied to separate @to and @cc
that are primed by the former and tweaked per message.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] send-email: Don't leak To: headers between patches
  2010-10-04  8:00       ` Junio C Hamano
@ 2010-10-04 18:55         ` Joe Perches
  0 siblings, 0 replies; 9+ messages in thread
From: Joe Perches @ 2010-10-04 18:55 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Ævar Arnfjörð Bjarmason, Stephen Boyd,
	Viresh Kumar, git

On Mon, 2010-10-04 at 01:00 -0700, Junio C Hamano wrote:
> I would prefer to keep @initial_to and @initial_cc as "these apply
> globally to the whole command invocation", copied to separate @to and @cc
> that are primed by the former and tweaked per message.

Makes sense to me, thanks.

Is there a need to add initial_to and
initial_cc to the test suite for a patch
series?  I believe the test suite is
currently setup for single patch testing.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2010-10-04 18:55 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-04  5:37 [PATCH] send-email: Clear To: field for every mail Viresh KUMAR
2010-10-04  7:05 ` [PATCH] send-email: Don't leak To: headers between patches Stephen Boyd
2010-10-04  7:11   ` Junio C Hamano
2010-10-04  7:15   ` Ævar Arnfjörð Bjarmason
2010-10-04  7:25     ` Ævar Arnfjörð Bjarmason
2010-10-04  8:00       ` Junio C Hamano
2010-10-04 18:55         ` Joe Perches
2010-10-04  7:09 ` [PATCH] send-email: Clear To: field for every mail Junio C Hamano
2010-10-04  7:49   ` viresh kumar

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).