# [PATCH] post-receive-email: allow customizing of subject/intro/footer 5 messages from 2010-01-19 to 2010-01-21. Participants: Mike Frysinger, Marc Branchaud, Junio C Hamano. Thread: https://gitlist.dev/t/22280 ## Mike Frysinger, 2010-01-19 05:12 Subject: [PATCH] post-receive-email: allow customizing of subject/intro/footer Message-ID: <1263877931-26047-1-git-send-email-vapier@gentoo.org> URL: https://gitlist.dev/e/1263877931-26047-1-git-send-email-vapier%40gentoo.org ``` The format of the subject/intro/footer are noise imo, but rather than debate the issue, let the user customize the output using the existing git config hooks section. The default output is retained for each part. Signed-off-by: Mike Frysinger --- contrib/hooks/post-receive-email | 76 +++++++++++++++++++++++++++++--------- 1 files changed, 58 insertions(+), 18 deletions(-) diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email index 58a35c8..79ab6b1 100755 --- a/contrib/hooks/post-receive-email +++ b/contrib/hooks/post-receive-email @@ -38,6 +38,15 @@ # hooks.emailprefix # All emails have their subjects prefixed with this prefix, or "[SCM]" # if emailprefix is unset, to aid filtering +# hooks.emailsubject +# Allow customizing of the subject. Default is a description of what +# ref changed and how/why. +# hooks.emailbodyintro +# Allow customizing of the body intro. Default is friendly paragraph that +# explains why the user is receiving this e-mail and what has changed. +# hooks.emailfooter +# Allow customizing of the footer. Default is name of the script and the +# repo description. # hooks.showrev # The shell command used to format each revision in the email, with # "%s" replaced with the commit id. Defaults to "git rev-list -1 @@ -55,6 +64,10 @@ # "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and # give information for debugging. # +# All variables that start with 'email' have substitution performed on them. +# Patterns like @foo@ are replaced with the contents of the variable foo. +# See subst_vars() for the specific keywords available for substitution. +# # ---------------------------- Functions @@ -190,36 +203,47 @@ generate_email() generate_email_footer } +subst_vars() +{ + sep=$(printf '\001') + # let this be used in a pipeline or by itself + ( [ "$#" -ne 0 ] && echo "$@" || cat ) | sed \ + -e "s${sep}@change_type@${sep}${change_type}${sep}g" \ + -e "s${sep}@describe@${sep}${describe}${sep}g" \ + -e "s${sep}@newrev@${sep}${newrev}${sep}g" \ + -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \ + -e "s${sep}@projectdesc@${sep}${projectdesc}${sep}g" \ + -e "s${sep}@refname@${sep}${refname}${sep}g" \ + -e "s${sep}@refname_type@${sep}${refname_type}${sep}g" \ + -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \ + -e "s${sep}@short_refname@${sep}${short_refname}${sep}g" +} + generate_email_header() { # --- Email (all stdout will be the email) # Generate header + ( cat <<-EOF To: $recipients - Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe - X-Git-Refname: $refname - X-Git-Reftype: $refname_type - X-Git-Oldrev: $oldrev - X-Git-Newrev: $newrev + Subject: ${emailprefix}${emailsubject} + X-Git-Refname: @refname@ + X-Git-Reftype: @refname_type@ + X-Git-Oldrev: @oldrev@ + X-Git-Newrev: @newrev@ + EOF - 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 - the project "$projectdesc". + if [ -n "${emailbodyintro}" ] ; then + printf '\n%s\n' "${emailbodyintro}" + fi - The $refname_type, $short_refname has been ${change_type}d - EOF + printf '\n%s\n' "The @refname_type@, @short_refname@ has been @change_type@d" + ) | subst_vars } generate_email_footer() { - SPACE=" " - cat <<-EOF - - - hooks/post-receive - --${SPACE} - $projectdesc - EOF + subst_vars "${emailfooter}" } # --------------- Branches @@ -671,6 +695,22 @@ recipients=$(git config hooks.mailinglist) announcerecipients=$(git config hooks.announcelist) envelopesender=$(git config hooks.envelopesender) emailprefix=$(git config hooks.emailprefix || echo '[SCM] ') +emailsubject=$(git config hooks.emailsubject || \ + echo '@projectdesc@ @refname_type@, @short_refname@, @change_type@d. @describe@') +emailbodyintro=$(git config hooks.emailbodyintro || cat <<-EOF + 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 + the project "@projectdesc@". + EOF +) +emailfooter=$(git config hooks.emailfooter || SPACE=" " cat <<-EOF + + + hooks/post-receive + --${SPACE} + @projectdesc@ + EOF +) custom_showrev=$(git config hooks.showrev) # --- Main loop -- 1.6.6 ``` ## Marc Branchaud, 2010-01-21 17:02 Subject: Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer Message-ID: <4B5888C2.60508@xiplink.com> URL: https://gitlist.dev/e/4B5888C2.60508%40xiplink.com In-Reply-To: <1263877931-26047-1-git-send-email-vapier@gentoo.org> ``` Thanks for this! I've been meaning to do something similar myself. :) A couple of thoughts struck me while looking through your patch... Mike Frysinger wrote: > The format of the subject/intro/footer are noise imo, but rather than > debate the issue, let the user customize the output using the existing > git config hooks section. The default output is retained for each part. > > Signed-off-by: Mike Frysinger > --- > contrib/hooks/post-receive-email | 76 +++++++++++++++++++++++++++++--------- > 1 files changed, 58 insertions(+), 18 deletions(-) > > diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email > index 58a35c8..79ab6b1 100755 > --- a/contrib/hooks/post-receive-email > +++ b/contrib/hooks/post-receive-email > @@ -38,6 +38,15 @@ > # hooks.emailprefix > # All emails have their subjects prefixed with this prefix, or "[SCM]" > # if emailprefix is unset, to aid filtering > +# hooks.emailsubject > +# Allow customizing of the subject. Default is a description of what > +# ref changed and how/why. > +# hooks.emailbodyintro > +# Allow customizing of the body intro. Default is friendly paragraph that > +# explains why the user is receiving this e-mail and what has changed. > +# hooks.emailfooter > +# Allow customizing of the footer. Default is name of the script and the > +# repo description. > # hooks.showrev > # The shell command used to format each revision in the email, with > # "%s" replaced with the commit id. Defaults to "git rev-list -1 > @@ -55,6 +64,10 @@ > # "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and > # give information for debugging. > # > +# All variables that start with 'email' have substitution performed on them. > +# Patterns like @foo@ are replaced with the contents of the variable foo. > +# See subst_vars() for the specific keywords available for substitution. > +# > > # ---------------------------- Functions > > @@ -190,36 +203,47 @@ generate_email() > generate_email_footer > } > > +subst_vars() > +{ > + sep=$(printf '\001') > + # let this be used in a pipeline or by itself > + ( [ "$#" -ne 0 ] && echo "$@" || cat ) | sed \ > + -e "s${sep}@change_type@${sep}${change_type}${sep}g" \ > + -e "s${sep}@describe@${sep}${describe}${sep}g" \ > + -e "s${sep}@newrev@${sep}${newrev}${sep}g" \ > + -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \ > + -e "s${sep}@projectdesc@${sep}${projectdesc}${sep}g" \ > + -e "s${sep}@refname@${sep}${refname}${sep}g" \ > + -e "s${sep}@refname_type@${sep}${refname_type}${sep}g" \ > + -e "s${sep}@oldrev@${sep}${oldrev}${sep}g" \ > + -e "s${sep}@short_refname@${sep}${short_refname}${sep}g" > +} > + > generate_email_header() > { > # --- Email (all stdout will be the email) > # Generate header > + ( > cat <<-EOF > To: $recipients > - Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe > - X-Git-Refname: $refname > - X-Git-Reftype: $refname_type > - X-Git-Oldrev: $oldrev > - X-Git-Newrev: $newrev > + Subject: ${emailprefix}${emailsubject} > + X-Git-Refname: @refname@ > + X-Git-Reftype: @refname_type@ > + X-Git-Oldrev: @oldrev@ > + X-Git-Newrev: @newrev@ > + EOF > > - 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 > - the project "$projectdesc". > + if [ -n "${emailbodyintro}" ] ; then Since the script ensures there's always a value set for emailbodyintro, why check for it here? None of the other uses of the new config items (emailsubject and emailfooter) have this kind of check. > + printf '\n%s\n' "${emailbodyintro}" > + fi > > - The $refname_type, $short_refname has been ${change_type}d > - EOF > + printf '\n%s\n' "The @refname_type@, @short_refname@ has been @change_type@d" > + ) | subst_vars Any reason why that last printf'd line shouldn't be made part of the emailbodyintro? So, overall, why not make generate_email_header() be simply: generate_email_header() { # --- Email (all stdout will be the email) # Generate header subst_vars <<-EOF To: $recipients Subject: ${emailprefix}${emailsubject} X-Git-Refname: @refname@ X-Git-Reftype: @refname_type@ X-Git-Oldrev: @oldrev@ X-Git-Newrev: @newrev@ ${emailbodyintro} EOF } This would also let you simply subst_vars() so that it needn't support piped invocations, no? (Not a very drastic simplification, but still...) M. > } > > generate_email_footer() > { > - SPACE=" " > - cat <<-EOF > - > - > - hooks/post-receive > - --${SPACE} > - $projectdesc > - EOF > + subst_vars "${emailfooter}" > } > > # --------------- Branches > @@ -671,6 +695,22 @@ recipients=$(git config hooks.mailinglist) > announcerecipients=$(git config hooks.announcelist) > envelopesender=$(git config hooks.envelopesender) > emailprefix=$(git config hooks.emailprefix || echo '[SCM] ') > +emailsubject=$(git config hooks.emailsubject || \ > + echo '@projectdesc@ @refname_type@, @short_refname@, @change_type@d. @describe@') > +emailbodyintro=$(git config hooks.emailbodyintro || cat <<-EOF > + 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 > + the project "@projectdesc@". > + EOF > +) > +emailfooter=$(git config hooks.emailfooter || SPACE=" " cat <<-EOF > + > + > + hooks/post-receive > + --${SPACE} > + @projectdesc@ > + EOF > +) > custom_showrev=$(git config hooks.showrev) > > # --- Main loop ``` ## Mike Frysinger, 2010-01-21 17:59 Subject: Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer Message-ID: <201001211259.30704.vapier@gentoo.org> URL: https://gitlist.dev/e/201001211259.30704.vapier%40gentoo.org In-Reply-To: <4B5888C2.60508@xiplink.com> ``` On Thursday 21 January 2010 12:02:58 Marc Branchaud wrote: > > + if [ -n "${emailbodyintro}" ] ; then > > + printf '\n%s\n' "${emailbodyintro}" > > + fi > > Since the script ensures there's always a value set for emailbodyintro, why > check for it here? None of the other uses of the new config items > (emailsubject and emailfooter) have this kind of check. the other values dont have newlines added to them implicitly. if it's empty, i dont want to useless newlines at the start of the e-mail. > > - The $refname_type, $short_refname has been ${change_type}d > > - EOF > > + printf '\n%s\n' "The @refname_type@, @short_refname@ has been > > @change_type@d" + ) | subst_vars > > Any reason why that last printf'd line shouldn't be made part of the > emailbodyintro? that could work > So, overall, why not make generate_email_header() be simply: > > generate_email_header() > { > # --- Email (all stdout will be the email) > # Generate header > subst_vars <<-EOF > To: $recipients > Subject: ${emailprefix}${emailsubject} > X-Git-Refname: @refname@ > X-Git-Reftype: @refname_type@ > X-Git-Oldrev: @oldrev@ > X-Git-Newrev: @newrev@ > > ${emailbodyintro} > > EOF > } > > This would also let you simply subst_vars() so that it needn't support > piped invocations, no? (Not a very drastic simplification, but still...) if emailbodyintro is empty, this adds two useless newlines. otherwise, this would be fine i think. -mike ``` ## Marc Branchaud, 2010-01-21 18:18 Subject: Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer Message-ID: <4B589A87.2090808@xiplink.com> URL: https://gitlist.dev/e/4B589A87.2090808%40xiplink.com In-Reply-To: <201001211259.30704.vapier@gentoo.org> ``` Mike Frysinger wrote: > On Thursday 21 January 2010 12:02:58 Marc Branchaud wrote: >> >> So, overall, why not make generate_email_header() be simply: >> >> generate_email_header() >> { >> # --- Email (all stdout will be the email) >> # Generate header >> subst_vars <<-EOF >> To: $recipients >> Subject: ${emailprefix}${emailsubject} >> X-Git-Refname: @refname@ >> X-Git-Reftype: @refname_type@ >> X-Git-Oldrev: @oldrev@ >> X-Git-Newrev: @newrev@ >> >> ${emailbodyintro} >> >> EOF >> } >> >> This would also let you simply subst_vars() so that it needn't support >> piped invocations, no? (Not a very drastic simplification, but still...) > > if emailbodyintro is empty, this adds two useless newlines. otherwise, this > would be fine i think. Personally, I can live with that limitation. I think it's unlikely that anyone will want to get rid of the intro entirely, though maybe that's just me. One alternative is to remove the newline after ${emailbodyintro}, but I think most users will want the newline after the intro and that it's too easy to forget to put it there when editing the setting. Anyway, I don't have a strong opinion on the newline question. The main change I'd like to see is including that last intro line in emailbodyintro instead of hardwiring it into the code. M. ``` ## Junio C Hamano, 2010-01-21 20:09 Subject: Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer Message-ID: <7v636vp6cw.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v636vp6cw.fsf%40alter.siamese.dyndns.org In-Reply-To: <201001211259.30704.vapier@gentoo.org> ``` Mike Frysinger writes: >> So, overall, why not make generate_email_header() be simply: >> >> generate_email_header() >> { >> # --- Email (all stdout will be the email) >> # Generate header >> subst_vars <<-EOF >> To: $recipients >> Subject: ${emailprefix}${emailsubject} >> X-Git-Refname: @refname@ >> X-Git-Reftype: @refname_type@ >> X-Git-Oldrev: @oldrev@ >> X-Git-Newrev: @newrev@ >> >> ${emailbodyintro} >> >> EOF >> } >> >> This would also let you simply subst_vars() so that it needn't support >> piped invocations, no? (Not a very drastic simplification, but still...) > > if emailbodyintro is empty, this adds two useless newlines. otherwise, this > would be fine i think. I haven't looked at the original that is being improved upon (because I am not very interested in this sample script myself), but I have two comments on the above. - You can do something like this to fix that "empty line" issue, no? LF=' ' ;# newline subst_vars <<-EOF ... ${emailbodyintro:+"$emailbodyinto$LF"} EOF - If you are using shell variable interpolation anyway, why do you still need @special_name@ interpolated with perl or sed or whatever you are using in subst_vars (which I didn't look at)? If you have $refname, $refname_type and friends, can't the above become "cat <<-EOF"? ```