[PATCH] send-email: new 'add-envelope' option

[PATCH] send-email: new 'add-envelope' option

[Felipe Contreras]

Some MTAs make smart decisions based on the 'from' envelope (i.e. msmtp)

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 git-send-email.perl |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..92bf491 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -140,6 +140,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
 	$author,$sender,$smtp_authpass,$annotate,$compose,$time);
 
 my $envelope_sender;
+my $envelope_from;
 
 # Example reply to:
 #$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
@@ -208,6 +209,7 @@ my %config_settings = (
     "aliasesfile" => \@alias_files,
     "suppresscc" => \@suppress_cc,
     "envelopesender" => \$envelope_sender,
+    "envelopefrom" => \$envelope_from,
     "multiedit" => \$multiedit,
     "confirm"   => \$confirm,
     "from" => \$sender,
@@ -265,6 +267,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
 		    "confirm=s" => \$confirm,
 		    "dry-run" => \$dry_run,
 		    "envelope-sender=s" => \$envelope_sender,
+		    "envelope-from" => \$envelope_from,
 		    "thread!" => \$thread,
 		    "validate!" => \$validate,
 		    "format-patch!" => \$format_patch,
@@ -861,10 +864,13 @@ X-Mailer: git-send-email $gitversion
 
 	my @sendmail_parameters = ('-i', @recipients);
 	my $raw_from = $sanitized_sender;
-	$raw_from = $envelope_sender if (defined $envelope_sender);
+	if (defined $envelope_sender) {
+		$raw_from = $envelope_sender;
+		$envelope_from = 1;
+	}
 	$raw_from = extract_valid_address($raw_from);
 	unshift (@sendmail_parameters,
-			'-f', $raw_from) if(defined $envelope_sender);
+			'-f', $raw_from) if(defined $envelope_from);
 
 	if ($needs_confirm && !$dry_run) {
 		print "\n$header\n";
-- 
1.6.5.3.1.ga9388c

Re: [PATCH] send-email: new 'add-envelope' option

[Jeff King]

On Sat, Nov 21, 2009 at 07:43:30PM +0200, Felipe Contreras wrote:

> Some MTAs make smart decisions based on the 'from' envelope (i.e. msmtp)

So my first thought was "how in the world is this different from setting
the envelope sender?"

Reading the code, it seems:

> -	$raw_from = $envelope_sender if (defined $envelope_sender);
> +	if (defined $envelope_sender) {
> +		$raw_from = $envelope_sender;
> +		$envelope_from = 1;
> +	}
>  	$raw_from = extract_valid_address($raw_from);
>  	unshift (@sendmail_parameters,
> -			'-f', $raw_from) if(defined $envelope_sender);
> +			'-f', $raw_from) if(defined $envelope_from);

that this is a boolean to mean "use the from address as the envelope
sender".

It was of course all the more confusing for not being documented at all,
but even if documented, --envelope-from is IMHO confusingly similar to
--envelope-sender. Maybe --use-from-in-envelope would be a better name?

And of course, your patch is missing docs and tests.

-Peff

Re: [PATCH] send-email: new 'add-envelope' option

[Felipe Contreras]

On Sat, Nov 21, 2009 at 9:36 PM, Jeff King <peff@peff.net> wrote:
> So my first thought was "how in the world is this different from setting
> the envelope sender?"
>
> Reading the code, it seems:

[...]

> that this is a boolean to mean "use the from address as the envelope
> sender".
>
> It was of course all the more confusing for not being documented at all,
> but even if documented,

Right, I forgot the one-liner for the help.

> --envelope-from is IMHO confusingly similar to
> --envelope-sender. Maybe --use-from-in-envelope would be a better name?

Ok. I don't have any opinion on the name.

> And of course, your patch is missing docs and tests.

There are no tests for 'envelope-sender', so I don't think it should
be a requirement for this patch to do so. I'll add the documentation
though.

Will resend v2.

-- 
Felipe Contreras

Re: [PATCH] send-email: new 'add-envelope' option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> There are no tests for 'envelope-sender', so I don't think it should
> be a requirement for this patch to do so....

The fact that the lack of test was pointed out as a problem makes it a
requirement.  Others' earlier mistakes are not an excuse for you to do a
poor job.

I do use --envelope-sender when sending patches out via msmtp.  What
wonderful things this patch adds am I missing in my current setup?

Re: [PATCH] send-email: new 'add-envelope' option

[Felipe Contreras]

On Sun, Nov 22, 2009 at 4:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> There are no tests for 'envelope-sender', so I don't think it should
>> be a requirement for this patch to do so....
>
> The fact that the lack of test was pointed out as a problem makes it a
> requirement.  Others' earlier mistakes are not an excuse for you to do a
> poor job.

Maybe I should wait until somebody adds the tests to --envelope-sender
before pushing this patch.

> I do use --envelope-sender when sending patches out via msmtp.  What
> wonderful things this patch adds am I missing in my current setup?

You need to specify your mail address when setting the variable,
right? I use multiple email addresses, so that when I change it
($EMAIL or user.email) the right one will be used in the envelope. If
I use 'sendemail.envelopesender' I would
 need to change it as well.

Another option is to do something like 'sendemail.envelopesender=auto'.

-- 
Felipe Contreras

Re: [PATCH] send-email: new 'add-envelope' option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> I do use --envelope-sender when sending patches out via msmtp.  What
>> wonderful things this patch adds am I missing in my current setup?
>
> You need to specify your mail address when setting the variable, right?
> I use multiple email addresses, so that when I change it ($EMAIL or
> user.email) the right one will be used in the envelope. If I use
> 'sendemail.envelopesender' I would need to change it as well.

Ahh, I see.  The above would be a good addition to the documentation part
of the patch.

Re: [PATCH] send-email: new 'add-envelope' option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Maybe I should wait until somebody adds the tests to --envelope-sender
> before pushing this patch.

You can say that if you want to be difficult to work with, or you can be
that somebody yourself and make a difference.

Let me show you that we can be constructive for a change ;-)

How about something trivial like this?

-- >8 --
Subject: [PATCH] t9001: test --envelope-sender option of send-email

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t9001-send-email.sh |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 84a7f03..004e81c 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -95,6 +95,23 @@ test_expect_success \
     'Verify commandline' \
     'test_cmp expected commandline1'
 
+test_expect_success 'Send patches with --envelope-sender' '
+    clean_fake_sendmail &&
+     git send-email --envelope-sender="Patch Contributer <patch@example.com>" --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
+'
+
+cat >expected <<\EOF
+!patch@example.com!
+!-i!
+!nobody@example.com!
+!author@example.com!
+!one@example.com!
+!two@example.com!
+EOF
+test_expect_success \
+    'Verify commandline' \
+    'test_cmp expected commandline1'
+
 cat >expected-show-all-headers <<\EOF
 0001-Second.patch
 (mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'

Re: [PATCH] send-email: new 'add-envelope' option

[Felipe Contreras]

On Sun, Nov 22, 2009 at 7:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> You can say that if you want to be difficult to work with, or you can be
> that somebody yourself and make a difference.

Being difficult to work with goes both ways. You as a maintainer are
entitled to say "I won't accept this without test cases", and I as a
contributor am entitled to say "I'm not going to do that". Since I'm
doing this on my free time I'd rather work on the things I like, which
doesn't include writing test cases from scratch, primarily because I'm
not familiar with them.

> Let me show you that we can be constructive for a change ;-)
>
> How about something trivial like this?

Looks good to me, but again, that doesn't say much.

Cheers.

-- 
Felipe Contreras

Re: [PATCH] send-email: new 'add-envelope' option

[Felipe Contreras]

On Sat, Nov 21, 2009 at 9:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sat, Nov 21, 2009 at 9:36 PM, Jeff King <peff@peff.net> wrote:
>> --envelope-from is IMHO confusingly similar to
>> --envelope-sender. Maybe --use-from-in-envelope would be a better name?
>
> Ok. I don't have any opinion on the name.

I thought a bit more about this, and in the end what we really want is
to add the sender envelope. The most typical case would be to use the
'from' address, but we should be able to override it (we do both by
using --envelope-sender).

So here are other options.

a) --add-envelope: add the sender envelope, by default it would be the
'from' address, but could be overridden by --envelope-sender.

b) --envelope-sender="" or "auto": this would require minimal changes
but looks a bit strange.

Any thoughts?

-- 
Felipe Contreras

Re: [PATCH] send-email: new 'add-envelope' option

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> I thought a bit more about this, and in the end what we really want is
> to add the sender envelope. The most typical case would be to use the
> 'from' address, but we should be able to override it (we do both by
> using --envelope-sender).
>
> So here are other options.
>
> a) --add-envelope: add the sender envelope, by default it would be the
> 'from' address, but could be overridden by --envelope-sender.

I do not think the latter half of this description makes much sense, as
the existing --envelope-sender=<this-address> alone already says "add this
envelope sender".

It is unfortunate that we cannot sanely have an option that takes an
optional string argument from the command line.  Ideally, if we can
specify --envelope-sender without any argument, we could make it to mean
"pretend as if the 'from' address is given to this option", but that would
make the command line pasing ambiguous, so we would need an extra option
like this one.  "--envelope-sender=from" might be a more intuitive way to
say this, though.

> b) --envelope-sender="" or "auto": this would require minimal changes
> but looks a bita strange.

An explicit empty string does look very strange, but I do not think a
magic word like "auto" (or "from") that cannot sanely be your envelope
sender address is a bad idea.

> Any thoughts?

It is much easier to work on the configuration front, by the way, and I
expect people who regularly interact with multiple projects to appreciate
this feature would configure their send-email once and forget about it, so
the command line clunkiness might not be such a big issue.

A user who works with more than one projects with different identity known
to each project would use $HOME/.gitconfig and send-email configuration
identity feature to set "sendemail.<identity>.from" and friends in there,
while setting sendemail.identity configuration in .git/config for each
project, so being able to say "use whatever 'from' as the envelope sender"
once in $HOME/.gitconfig would be convenient.

So I could have in $HOME/.gitconfig:

        [sendemail]
		; used as a boolean to say "use from"
                envelopesender
        [sendemail.git]
                from = Junio C Hamano <gitster@pobox.com>
                to = git mailing list <git@vger.kernel.org>
        [sendemail.frotz]
                from = Junio C Hamano <frotzster@example.xz>
                to = frotz mailing list <frotz@example.xz>

and then in my {git,frotz}.git/.git/config would have

        [sendemail]                     [sendemail]
                identity = git                  identity = frotz

respectively.  Without your patch, in $HOME/.gitconfig, I wouldn't have
the global sendemail.envelopesender but have separate individual
configuration variables sendemail.{git,frotz}.envelopesender defined.

Re: [PATCH] send-email: new 'add-envelope' option

[Felipe Contreras]

On Mon, Nov 23, 2009 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> a) --add-envelope: add the sender envelope, by default it would be the
>> 'from' address, but could be overridden by --envelope-sender.
>
> I do not think the latter half of this description makes much sense, as
> the existing --envelope-sender=<this-address> alone already says "add this
> envelope sender".

--envelope-sender=foo@bar.com would imply --add-envelope.

> It is unfortunate that we cannot sanely have an option that takes an
> optional string argument from the command line.  Ideally, if we can
> specify --envelope-sender without any argument, we could make it to mean
> "pretend as if the 'from' address is given to this option", but that would
> make the command line pasing ambiguous, so we would need an extra option
> like this one.  "--envelope-sender=from" might be a more intuitive way to
> say this, though.

I agree, but --envelope-sender=from looks a bit strange to me.

>> b) --envelope-sender="" or "auto": this would require minimal changes
>> but looks a bita strange.
>
> An explicit empty string does look very strange, but I do not think a
> magic word like "auto" (or "from") that cannot sanely be your envelope
> sender address is a bad idea.

I think "auto" is the least worst option right now.

>> Any thoughts?
>
> It is much easier to work on the configuration front, by the way, and I
> expect people who regularly interact with multiple projects to appreciate
> this feature would configure their send-email once and forget about it, so
> the command line clunkiness might not be such a big issue.
>
> A user who works with more than one projects with different identity known
> to each project would use $HOME/.gitconfig and send-email configuration
> identity feature to set "sendemail.<identity>.from" and friends in there,
> while setting sendemail.identity configuration in .git/config for each
> project, so being able to say "use whatever 'from' as the envelope sender"
> once in $HOME/.gitconfig would be convenient.
>
> So I could have in $HOME/.gitconfig:
>
>        [sendemail]
>                ; used as a boolean to say "use from"
>                envelopesender
>        [sendemail.git]
>                from = Junio C Hamano <gitster@pobox.com>
>                to = git mailing list <git@vger.kernel.org>
>        [sendemail.frotz]
>                from = Junio C Hamano <frotzster@example.xz>
>                to = frotz mailing list <frotz@example.xz>
>
> and then in my {git,frotz}.git/.git/config would have
>
>        [sendemail]                     [sendemail]
>                identity = git                  identity = frotz
>
> respectively.  Without your patch, in $HOME/.gitconfig, I wouldn't have
> the global sendemail.envelopesender but have separate individual
> configuration variables sendemail.{git,frotz}.envelopesender defined.

I also thought about having an identity (profile) for sendmail; it
would be very useful to specify the smtp server, aliases file, and
from address that multiple repositories can share and can be easily
changed (working for my company vs working for myself).

However, even in this case I would like to have a global option to add
the sender automatically from the 'from' address.

-- 
Felipe Contreras