threads / patch / 16140

patchcontrib/hooks/post-receive-email: Make revision display configurable

Subject: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable

## tl;dr

6 messages between Nov 2, 2008 and Nov 4, 2008. Diffs are folded; open one to read it.

replies: 5people: 3as markdown or json

Pete Harlan· Nov 2, 2008, 23:20 UTC · lore

Add configuration option hooks.showrev, letting the user override how revisions will be shown in the commit email.

Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---

This allows, for example, to show full diffs in the post-receive email to simply after-the-fact reviewing of commits. Perhaps others would find this useful also.

 contrib/hooks/post-receive-email |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)
Show changes to contrib/hooks/post-receive-email +14 −2
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 4136895..a365c3f 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -38,6 +38,12 @@
 # hooks.emailprefix
 #   All emails have their subjects prefixed with this prefix, or "[SCM]"
 #   if emailprefix is unset, to aid filtering
+# 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
+#   --pretty %s", displaying the commit id, author, date and log
+#   message.  To list full patches separated by a blank line, you
+#   could set this to "git show -C %s; echo".
 #
 # Notes
 # -----
@@ -390,8 +396,13 @@ generate_update_branch_email()
 
 		echo ""
 		echo $LOGBEGIN
-		git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
-		git rev-list --pretty --stdin $oldrev..$newrev
+		git rev-parse --not --branches |
+			grep -v $(git rev-parse $refname) |
+			git rev-list --stdin $oldrev..$newrev |
+		while read onerev
+		do
+			eval $(printf "$showrev" $onerev)
+		done
 
 		# XXX: Need a way of detecting whether git rev-list actually
 		# outputted anything, so that we can issue a "no new
@@ -627,6 +638,7 @@ recipients=$(git config hooks.mailinglist)
 announcerecipients=$(git config hooks.announcelist)
 envelopesender=$(git config hooks.envelopesender)
 emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
+showrev=$(git config hooks.showrev || echo 'git rev-list -1 --pretty %s')
 
 # --- Main loop
 # Allow dual mode: run from the command line just like the update hook, or

-- 
1.6.0.3.533.ge0502
Pete Harlan· Nov 2, 2008, 23:24 UTC · re: Pete Harlan · lore

Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable

Sorry for the repeat emails....this first-time "git send-email" user was a little surprised that it appears to always cc git@vger...

<hides behind rock>
--Pete
Pete Harlan wrote:
> Add configuration option hooks.showrev, letting the user override how
> revisions will be shown in the commit email.
Pete Harlan· Nov 3, 2008, 09:49 UTC · re: Pete Harlan · lore

Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable

Pete Harlan wrote:
> Sorry for the repeat emails....this first-time "git send-email" user was
> a little surprised that it appears to always cc git@vger...

No, Pete, it only cc'd the "Signed-of-by:" address, which you filtered to your git-list mailbox.

Sorry for this noise.  I'll get the hang of things sooner or later.

If you think the patch, or the idea, could be worth applying in some form, I'd appreciate any feedback.

Thanks,
--Pete
Show 13 quoted lines
> 
> <hides behind rock>
> 
> --Pete
> 
> Pete Harlan wrote:
>> Add configuration option hooks.showrev, letting the user override how
>> revisions will be shown in the commit email.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andy Parkins· Nov 3, 2008, 18:58 UTC · re: Pete Harlan · lore

Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable

On Sunday 02 November 2008 23:20:59 Pete Harlan wrote:
> Add configuration option hooks.showrev, letting the user override how
> revisions will be shown in the commit email.
>
> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
Acked-By: Andy Parkins <andyparkins@gmail.com>
-- 
Dr Andy Parkins
andyparkins@gmail.com
Junio C Hamano· Nov 3, 2008, 23:34 UTC · re: Pete Harlan · lore

Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable

Pete Harlan <pgit@pcharlan.com> writes:
Show 18 quoted lines
> Add configuration option hooks.showrev, letting the user override how
> revisions will be shown in the commit email.
>
> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
> Acked-By: Andy Parkins <andyparkins@gmail.com>
> @@ -390,8 +396,13 @@ generate_update_branch_email()
>  
>  		echo ""
>  		echo $LOGBEGIN
> -		git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
> -		git rev-list --pretty --stdin $oldrev..$newrev
> +		git rev-parse --not --branches |
> +			grep -v $(git rev-parse $refname) |
> +			git rev-list --stdin $oldrev..$newrev |
> +		while read onerev
> +		do
> +			eval $(printf "$showrev" $onerev)
> +		done

This would make the default "non-custom" case much less efficient. If we really cared, perhaps we could do something like this...

	git rev-parse --not --branches |
        grep -v "^$(git-rev-parse --not $refname)\$" |
        case "$using_custom_showrev" in
        yes)
		git rev-list --stdin $oldrev..$newrev |
        	while read onerev
                do
                done
                ;;
	*)
        	git rev-list --pretty --stdin $oldrev..newrev
                ;;
	esac
But I suspect we do not care too much about it.
Will apply as submitted.  Thanks
Pete Harlan· Nov 4, 2008, 00:45 UTC · re: Junio C Hamano · lore

Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable

Junio C Hamano wrote:
Show 39 quoted lines
> Pete Harlan <pgit@pcharlan.com> writes:
> 
>> Add configuration option hooks.showrev, letting the user override how
>> revisions will be shown in the commit email.
>>
>> Signed-off-by: Pete Harlan <pgit@pcharlan.com>
>> Acked-By: Andy Parkins <andyparkins@gmail.com>
>> @@ -390,8 +396,13 @@ generate_update_branch_email()
>>  
>>  		echo ""
>>  		echo $LOGBEGIN
>> -		git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
>> -		git rev-list --pretty --stdin $oldrev..$newrev
>> +		git rev-parse --not --branches |
>> +			grep -v $(git rev-parse $refname) |
>> +			git rev-list --stdin $oldrev..$newrev |
>> +		while read onerev
>> +		do
>> +			eval $(printf "$showrev" $onerev)
>> +		done
> 
> This would make the default "non-custom" case much less efficient.  If we
> really cared, perhaps we could do something like this...
> 
> 	git rev-parse --not --branches |
>         grep -v "^$(git-rev-parse --not $refname)\$" |
>         case "$using_custom_showrev" in
>         yes)
> 		git rev-list --stdin $oldrev..$newrev |
>         	while read onerev
>                 do
>                 done
>                 ;;
> 	*)
>         	git rev-list --pretty --stdin $oldrev..newrev
>                 ;;
> 	esac
> 
> But I suspect we do not care too much about it.

I agree about the efficiency; that bothered me when I wrote the patch, but figured the lack of efficiency wouldn't be noticeable.

OTOH, it still bothers me; I'll write up a v2 patch that does something much more like what you suggest.

Is it easier at this point for you to have a new patch that applies on top of my previous patch, or a wholesale replacement for it? Or is what's done done and that's the end of it for something this minor?

Thanks to you both for your time and work,
--Pete
Show 6 quoted lines
> 
> Will apply as submitted.  Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

← back to recent threads