Andy, do you have any thoughts on adding this email header to contrib/hooks/post-receive-email? This patch shouldn't cause problems for anyone with a sanely configured mail delivery agent, and the additional header is very useful in toggling auto responses. This conforms to RFC3834 and is useful in preventing eg vacation auto-responders from replying by default Signed-off-by: Chris Hiestand <chiestand@xxxxxxxx> --- contrib/hooks/post-receive-email | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email index b2171a0..0e5b72d 100755 --- a/contrib/hooks/post-receive-email +++ b/contrib/hooks/post-receive-email @@ -237,6 +237,7 @@ generate_email_header() X-Git-Reftype: $refname_type X-Git-Oldrev: $oldrev X-Git-Newrev: $newrev + Auto-Submitted: auto-generated This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing -- 1.7.10.4 On Sep 21, 2012, at 10:06 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Chris Hiestand <chiestand@xxxxxxxx> writes: > >> My email in April went unanswered so I'm resending it. An Auto-Submitted header >> would be an improvement to the standard [git] post receive email. >> >> Thanks, >> Chris >> >> >> Begin forwarded message: >> >>> From: Chris Hiestand <chiestand@xxxxxxxx> >>> Subject: [PATCH] Add Auto-Submitted header to post-receive-email >>> Date: April 14, 2012 6:15:10 PM PDT >>> To: git@xxxxxxxxxxxxxxx, gitster@xxxxxxxxx >>> >>> Hi, >>> >>> I think the Auto-Submitted header is a useful hook mail header to include by default. >>> >>> This conforms to RFC3834 and is useful in preventing e.g. vacation auto-responders >>> from replying by default. >>> >>> Perhaps you have already considered this and decided not to include it, but I found >>> no record of such a conversation on this list. > > I think the lack of response is generally lack of interest, and the > primary reason for that was because the To/Cc list did not contain > anybody who touched this particular file in the past (and no, I am > not among them; as contrib/README says, I am often the wrong person > to ask if a patch to contrib/ material makes sense). > >>> From 358fc3ae1ebfd7723d54e4033d3e9a9a0322c873 Mon Sep 17 00:00:00 2001 >>> From: Chris Hiestand <chiestand@xxxxxxxx> >>> Date: Sat, 14 Apr 2012 17:58:39 -0700 >>> Subject: [PATCH] Add Auto-Submitted header to post-receive-email > > These four lines should not be in the body of the e-mail message > (see Documentation/SubmittingPatches). > >>> Adds Auto-Submitted: auto-generated to post-receive-email header >>> This conforms to RFC3834 and is useful in preventing eg >>> vacation auto-responders from replying by default >>> --- >>> contrib/hooks/post-receive-email | 1 + >>> 1 files changed, 1 insertions(+), 0 deletions(-) > > Even for contrib/ material, please always sign-off your patch (see > Documentation/SubmittingPatches). > >>> >>> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email >>> index 01af9df..282507c 100755 >>> --- a/contrib/hooks/post-receive-email >>> +++ b/contrib/hooks/post-receive-email >>> @@ -237,6 +237,7 @@ generate_email_header() >>> X-Git-Reftype: $refname_type >>> X-Git-Oldrev: $oldrev >>> X-Git-Newrev: $newrev >>> + Auto-Submitted: auto-generated >>> >>> This is an automated email from the git hooks/post-receive script. It was >>> generated because a ref change was pushed to the repository containing > > I think the choice of "auto-generated" is a sensible one, as > responding to a 'push' is like triggered by 'cron'. > > I'd however appreciate comments from people who either worked on > this code or list regulars who actually use this code in the > production. > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html