threads / patch / 16289

patchcontrib/hooks/post-receive-email: send individual mails to recipients

Subject: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients

## tl;dr

5 messages between Nov 12, 2008 and Nov 12, 2008. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Michael Adam· Nov 12, 2008, 16:21 UTC · lore

This changes the behaviour of post-receive-email when a list of recipients (separated by commas) is specified as hooks.mailinglist. With this modification, an individual mail is sent out for each recipient entry in the list, instead of sending a single mail with all the recipients in the "To: " field.

Signed-off-by: Michael Adam <obnox@samba.org>
---
 contrib/hooks/post-receive-email |   30 +++++++++++++++++-------------
 1 files changed, 17 insertions(+), 13 deletions(-)

Show changes to contrib/hooks/post-receive-email +17 −13

diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 28a3c0e..5deaf28 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -169,21 +169,25 @@ generate_email()
 		describe=$rev
 	fi
 
-	generate_email_header
+	# loop over the recipients to send individual mails
+	echo $recipients | sed -e 's/\s*,\s*/\n/' | while read recipient
+	do
+		generate_email_header
 
-	# Call the correct body generation function
-	fn_name=general
-	case "$refname_type" in
-	"tracking branch"|branch)
-		fn_name=branch
-		;;
-	"annotated tag")
-		fn_name=atag
-		;;
-	esac
-	generate_${change_type}_${fn_name}_email
+		# Call the correct body generation function
+		fn_name=general
+		case "$refname_type" in
+		"tracking branch"|branch)
+			fn_name=branch
+			;;
+		"annotated tag")
+			fn_name=atag
+			;;
+		esac
+		generate_${change_type}_${fn_name}_email
 
-	generate_email_footer
+		generate_email_footer
+	done
 }
 
 generate_email_header()

-- 
1.5.6

Junio C Hamano· Nov 12, 2008, 17:49 UTC · re: Michael Adam · lore

Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients

Michael Adam <obnox@samba.org> writes:

> This changes the behaviour of post-receive-email when a list of recipients
> (separated by commas) is specified as hooks.mailinglist. With this modification,
> an individual mail is sent out for each recipient entry in the list, instead
> of sending a single mail with all the recipients in the "To: " field.

Why can that be an improvement?

Michael Adam· Nov 12, 2008, 17:58 UTC · re: Junio C Hamano · lore

Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients

Junio C Hamano wrote:

Show 8 quoted lines

> Michael Adam <obnox@samba.org> writes:
> 
> > This changes the behaviour of post-receive-email when a list of recipients
> > (separated by commas) is specified as hooks.mailinglist. With this modification,
> > an individual mail is sent out for each recipient entry in the list, instead
> > of sending a single mail with all the recipients in the "To: " field.
> 
> Why can that be an improvement?

My use case is that I have a repository where I want to send commit messages to an "official" mailing list and to a private recipient list that might not want to be seen on the official mailing list.

If this is not generally useful, I could make it optional or add s/th like a secondary mailing list argument to hooks.

Cheers - Michael

Junio C Hamano· Nov 12, 2008, 18:18 UTC · re: Michael Adam · lore

Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients

Michael Adam <obnox@samba.org> writes:

Show 14 quoted lines

> Junio C Hamano wrote:
>> Michael Adam <obnox@samba.org> writes:
>> 
>> > This changes the behaviour of post-receive-email when a list of recipients
>> > (separated by commas) is specified as hooks.mailinglist. With this modification,
>> > an individual mail is sent out for each recipient entry in the list, instead
>> > of sending a single mail with all the recipients in the "To: " field.
>> 
>> Why can that be an improvement?
>
> My use case is that I have a repository where I want to send
> commit messages to an "official" mailing list and to a private
> recipient list that might not want to be seen on the official
> mailing list.

Ah. What you want is a capability to add Bcc:, not a misfeature to run the log formatter repeatedly wasting cycles only to generate the same message contents.

Michael Adam· Nov 12, 2008, 22:21 UTC · re: Junio C Hamano · lore

Re: [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients

Junio C Hamano wrote:

Show 20 quoted lines

> Michael Adam <obnox@samba.org> writes:
> 
> > Junio C Hamano wrote:
> >> Michael Adam <obnox@samba.org> writes:
> >> 
> >> > This changes the behaviour of post-receive-email when a list of recipients
> >> > (separated by commas) is specified as hooks.mailinglist. With this modification,
> >> > an individual mail is sent out for each recipient entry in the list, instead
> >> > of sending a single mail with all the recipients in the "To: " field.
> >> 
> >> Why can that be an improvement?
> >
> > My use case is that I have a repository where I want to send
> > commit messages to an "official" mailing list and to a private
> > recipient list that might not want to be seen on the official
> > mailing list.
> 
> Ah.  What you want is a capability to add Bcc:, not a misfeature to run
> the log formatter repeatedly wasting cycles only to generate the same
> message contents.

The intent was to send out the mail not to a (large) list of individual recipients but to some (few) mailing lists separately. A Bcc would be a partial solution. I also thought about that, but I did not like it since it might make those recipients in the bcc field feel strange because they seem to be getting mail from a list they might not be subscribed to. Group-replying to such mails may also cause confusion...

Of course my patch could be optimized for not wasting cycles by only running generate_email_header() multiple times and caching the results of the log formatter and generate_email_footer().

But I understand that my problem is a very specific one and that generally no benefit but only disadvantage is seen in the modification I suggested. -- Sorry for the noise. :-)

Cheers - Michael