threads / patch / 21696

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

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

## tl;dr

11 messages between Nov 21, 2009 and Nov 24, 2009. Diffs are folded; open one to read it.

replies: 10people: 3as markdown or json

Felipe Contreras· Nov 21, 2009, 17:43 UTC · lore

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

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(-)
Show changes to git-send-email.perl +8 −2
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
Jeff King· Nov 21, 2009, 19:36 UTC · re: Felipe Contreras · lore
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:
Show 9 quoted lines
> -	$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
Felipe Contreras· Nov 21, 2009, 19:59 UTC · re: Jeff King · lore
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:
[...]
Show 5 quoted lines
> 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
Junio C Hamano· Nov 22, 2009, 02:58 UTC · re: Felipe Contreras · lore
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?

Felipe Contreras· Nov 22, 2009, 12:03 UTC · re: Junio C Hamano · lore
On Sun, Nov 22, 2009 at 4:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> 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
Junio C Hamano· Nov 22, 2009, 16:42 UTC · re: Felipe Contreras · lore
Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 7 quoted lines
>> 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.

Junio C Hamano· Nov 22, 2009, 17:54 UTC · re: Felipe Contreras · lore
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(-)
Show changes to t/t9001-send-email.sh +17 −0
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>'
Felipe Contreras· Nov 23, 2009, 20:13 UTC · re: Junio C Hamano · lore
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
Felipe Contreras· Nov 22, 2009, 12:37 UTC · re: Felipe Contreras · lore

On Sat, Nov 21, 2009 at 9:59 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 5 quoted lines
> 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
Junio C Hamano· Nov 22, 2009, 23:54 UTC · re: Felipe Contreras · lore
Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 9 quoted lines
> 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.

Felipe Contreras· Nov 24, 2009, 17:28 UTC · re: Junio C Hamano · lore
On Mon, Nov 23, 2009 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> 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.
Show 7 quoted lines
> 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.
Show 6 quoted lines
>> 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.
Show 34 quoted lines
>> 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

← back to recent threads