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

Subsystems: the rest

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:45

Felipe Contreras [off-list ref] 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 <redacted>
---
 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

From: Felipe Contreras <hidden>
Date: 2016-06-15 22:47:45

On Sun, Nov 22, 2009 at 7:54 PM, Junio C Hamano [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help