git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Kevin P. Fleming" <kpfleming@digium.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] post-receive-email: optional message line count limit
Date: Thu, 15 Jul 2010 10:36:55 -0700	[thread overview]
Message-ID: <7v1vb4wsso.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1279205516-3302-1-git-send-email-kpfleming@digium.com> (Kevin P. Fleming's message of "Thu\, 15 Jul 2010 09\:51\:56 -0500")

"Kevin P. Fleming" <kpfleming@digium.com> writes:

> We have become used to the features of svnmailer when used with Subversion,
> and one of those useful features is that it can limit the maximum length
> (in lines) of a commit email message. This is terribly useful since once the
> goes beyond a reasonable number of lines, nobody is going to read the remainder,
> and if they really want the entire contents of the commits, they can use
> git itself to get them using the revision IDs present in the message already.
>
> Change the post-receive-email script to respond to an 'emailmaxlines' config key
> which, if specified, will limit the number of lines generated (including
> headers); any lines beyond the limit are suppressed, and a final line is added
> indicating the number that were suppressed.
> ---

Sign-off?

> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index 30ae63d..4dc85c2 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -642,6 +647,27 @@ show_new_revisions()
>  }
>  
>  
> +limit_lines()
> +{
> +	lines=0
> +	skipped=0
> +	while IFS="" read -r line
> +	do
> +		lines=$((lines + 1))
> +		if [ $lines -gt $1 ]
> +		then

Since this is a contrib/ material, I should probably be not so picky about
it, but the style used in this script seems to be to use "; then" tacked
at the end on the same line as "if" is on.  Which is different from the
main scripted Porcelains in git.git, but you would want to be consistent
with the local convention around your code.

> +			skipped=$((skipped + 1))
> +		else
> +			printf "%s\n" "$line"
> +		fi
> +	done
> +	if [ $skipped -ne 0 ]
> +	then
> +		echo "... $skipped lines suppressed ..."
> +	fi
> +}

The above makes me wonder if the nicety of saying "we are not showing
everything; instead we skipped N lines" is really worth the trouble of the
shell loop.  Otherwise, a lot simpler:

	limit_lines ()
        {
        	head -n "$1"
	}

would be sufficient.  I dunno, and I don't deeply care either way.

> @@ -679,6 +705,7 @@ announcerecipients=$(git config hooks.announcelist)
>  envelopesender=$(git config hooks.envelopesender)
>  emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
>  custom_showrev=$(git config hooks.showrev)
> +maxlines=$(git config hooks.emailmaxlines)
>  
>  # --- Main loop
>  # Allow dual mode: run from the command line just like the update hook, or
> @@ -691,6 +718,10 @@ if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
>  else
>  	while read oldrev newrev refname
>  	do
> -		generate_email $oldrev $newrev $refname | send_mail
> +		if [ -z "$maxlines" ]; then
> +			generate_email $oldrev $newrev $refname | send_mail
> +		else
> +			generate_email $oldrev $newrev $refname | limit_lines $maxlines | send_mail
> +		fi

Hmm, the above made me wonder how the raw message needs to be generated
differently depending on maxlines and eyeball the common part for three
times to spot there is no difference.  I wouldn't have if it were written
this way:

	generate_email $oldrev $newrev $refname |
        if ...; then
        	send_mail
	else
        	limit_lines ... | send_mail
	fi

But more importantly, I have a suspicion that this patch is hooking into a
wrong place.  Look at what generate_email does.  It consists of calls to

 - generate_email_header, that gives the To:/Subject:/etc and the header
   boilerplate;

 - generate_*_*_email, that gives the body of the message; and

 - generate_email_footer, that gives the standard "-- " signature line.

You would never want to shorten the output so much that the header is cut
in the middle.  What you are trying to shorten is the body of the message,
so it would make a lot more sense to cut only the generate_*_*_email part.

IOW, shouldn't the patch be more like this?

diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 30ae63d..d8964b6 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -84,6 +84,7 @@ generate_email()
 	oldrev=$(git rev-parse $1)
 	newrev=$(git rev-parse $2)
 	refname="$3"
+	maxlines=$4
 
 	# --- Interpret
 	# 0000->1234 (create)
@@ -192,7 +193,12 @@ generate_email()
 		fn_name=atag
 		;;
 	esac
-	generate_${change_type}_${fn_name}_email
+	if [ -z "$maxlines" ]; then
+		generate_${change_type}_${fn_name}_email
+	else
+		generate_${change_type}_${fn_name}_email |
+		limit_lines $maxlines
+	fi
 
 	generate_email_footer
 }
@@ -691,6 +697,6 @@ if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
 else
 	while read oldrev newrev refname
 	do
-		generate_email $oldrev $newrev $refname | send_mail
+		generate_email $oldrev $newrev $refname $maxlines | send_mail
 	done
 fi

  reply	other threads:[~2010-07-15 17:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-08 19:03 [PATCH] Add support for limiting number of lines generated in messages by post-receive-email Kevin P. Fleming
2010-07-12 16:47 ` Marc Branchaud
2010-07-13 20:56   ` Kevin P. Fleming
2010-07-12 17:10 ` Ævar Arnfjörð Bjarmason
2010-07-13 21:18   ` [PATCH] Optional limit for number of lines generated by script Kevin P. Fleming
2010-07-13 21:43     ` Andreas Schwab
2010-07-15 14:51       ` [PATCH] post-receive-email: optional message line count limit Kevin P. Fleming
2010-07-15 17:36         ` Junio C Hamano [this message]
2010-07-16 19:13           ` Kevin P. Fleming
2010-07-16 19:16           ` Kevin P. Fleming
2010-07-14 16:41     ` [PATCH] Optional limit for number of lines generated by script Marc Branchaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v1vb4wsso.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kpfleming@digium.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).