threads / patch / 7364

patchupdate-hook: remove all functionality that should be in hooks/post-receive

Subject: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

## tl;dr

15 messages between Mar 23, 2007 and Mar 25, 2007. Diffs are folded; open one to read it.

replies: 14people: 6as markdown or json

Andy Parkins· Mar 23, 2007, 10:21 UTC · lore

Now that we have a post-receive hook; the update hook's only job is to decide is a particular update is allowed or not.

This example hook removes all of the functionality that should now rightly be done by the post-receive hook. In particular: the generation of notification emails.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Replacement of functionality removed by this patch with a post-receive hook
to follow.
 templates/hooks--update |  225 +----------------------------------------------
 1 files changed, 3 insertions(+), 222 deletions(-)
Show changes to templates/hooks--update +3 −221
diff --git a/templates/hooks--update b/templates/hooks--update
index 8f6c4fe..638d2d1 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -1,36 +1,16 @@
 #!/bin/sh
 #
-# An example hook script to mail out commit update information.
-# It can also blocks tags that aren't annotated.
+# An example hook script to blocks unannotated tags from entering.
 # Called by git-receive-pack with arguments: refname sha1-old sha1-new
 #
 # To enable this hook, make this file executable by "chmod +x update".
 #
 # Config
 # ------
-# hooks.mailinglist
-#   This is the list that all pushes will go to; leave it blank to not send
-#   emails frequently.  The log email will list every log entry in full between
-#   the old ref value and the new ref value.
-# hooks.announcelist
-#   This is the list that all pushes of annotated tags will go to.  Leave it
-#   blank to just use the mailinglist field.  The announce emails list the
-#   short log summary of the changes since the last annotated tag
 # hooks.allowunannotated
 #   This boolean sets whether unannotated tags will be allowed into the
 #   repository.  By default they won't be.
 #
-# Notes
-# -----
-# All emails have their subjects prefixed with "[SCM]" to aid filtering.
-# All emails include the headers "X-Git-Refname", "X-Git-Oldrev",
-# "X-Git-Newrev", and "X-Git-Reftype" to enable fine tuned filtering and info.
-
-# --- Constants
-EMAILPREFIX="[SCM] "
-LOGBEGIN="- Log -----------------------------------------------------------------"
-LOGEND="-----------------------------------------------------------------------"
-DATEFORMAT="%F %R %z"
 
 # --- Command line
 refname="$1"
@@ -51,9 +31,6 @@ if [ -z "$refname" -o -z "$oldrev" -o -z "$newrev" ]; then
 fi
 
 # --- Config
-projectdesc=$(cat $GIT_DIR/description)
-recipients=$(git-repo-config hooks.mailinglist)
-announcerecipients=$(git-repo-config hooks.announcelist)
 allowunannotated=$(git-repo-config --bool hooks.allowunannotated)
 
 # --- Check types
@@ -62,224 +39,28 @@ newrev_type=$(git-cat-file -t $newrev)
 case "$refname","$newrev_type" in
 	refs/tags/*,commit)
 		# un-annotated tag
-		refname_type="tag"
 		short_refname=${refname##refs/tags/}
 		if [ "$allowunannotated" != "true" ]; then
-			echo "*** The un-annotated tag, $short_refname is not allowed in this repository" >&2
+			echo "*** The un-annotated tag, $short_refname, is not allowed in this repository" >&2
 			echo "*** Use 'git tag [ -a | -s ]' for tags you want to propagate." >&2
 			exit 1
 		fi
 		;;
 	refs/tags/*,tag)
 		# annotated tag
-		refname_type="annotated tag"
-		short_refname=${refname##refs/tags/}
-		# change recipients
-		if [ -n "$announcerecipients" ]; then
-			recipients="$announcerecipients"
-		fi
 		;;
 	refs/heads/*,commit)
 		# branch
-		refname_type="branch"
-		short_refname=${refname##refs/heads/}
 		;;
 	refs/remotes/*,commit)
 		# tracking branch
-		refname_type="tracking branch"
-		short_refname=${refname##refs/remotes/}
-		# Should this even be allowed?
-		echo "*** Push-update of tracking branch, $refname.  No email generated." >&2
-		exit 0
 		;;
 	*)
 		# Anything else (is there anything else?)
-		echo "*** Update hook: unknown type of update, \"$newrev_type\", to ref $refname" >&2
+		echo "*** Update hook: unknown type of update to ref $refname of type $newrev_type" >&2
 		exit 1
 		;;
 esac
 
-# Check if we've got anyone to send to
-if [ -z "$recipients" ]; then
-	# If the email isn't sent, then at least give the user some idea of what command
-	# would generate the email at a later date
-	echo "*** No recipients found - no email will be sent, but the push will continue" >&2
-	echo "*** for $0 $1 $2 $3" >&2
-	exit 0
-fi
-
-# --- Email parameters
-committer=$(git show --pretty=full -s $newrev | grep "^Commit: " | sed -e "s/^Commit: //")
-describe=$(git describe $newrev 2>/dev/null)
-if [ -z "$describe" ]; then
-	describe=$newrev
-fi
-
-# --- Email (all stdout will be the email)
-(
-# Generate header
-cat <<-EOF
-From: $committer
-To: $recipients
-Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname now at $describe
-X-Git-Refname: $refname
-X-Git-Reftype: $refname_type
-X-Git-Oldrev: $oldrev
-X-Git-Newrev: $newrev
-
-Hello,
-
-This is an automated email from the git hooks/update script, it was
-generated because a ref change was pushed to the repository.
-
-Updating $refname_type, $short_refname,
-EOF
-
-case "$refname_type" in
-	"tracking branch"|branch)
-		if expr "$oldrev" : '0*$' >/dev/null
-		then
-			# If the old reference is "0000..0000" then this is a new branch
-			# and so oldrev is not valid
-			echo "  as a new  $refname_type"
-		    echo "        to  $newrev ($newrev_type)"
-			echo ""
-			echo $LOGBEGIN
-			# This shows all log entries that are not already covered by
-			# another ref - i.e. commits that are now accessible from this
-			# ref that were previously not accessible
-			git log $newrev --not --all
-			echo $LOGEND
-		else
-			# oldrev is valid
-			oldrev_type=$(git-cat-file -t "$oldrev")
-
-			# Now the problem is for cases like this:
-			#   * --- * --- * --- * (oldrev)
-			#          \
-			#           * --- * --- * (newrev)
-			# i.e. there is no guarantee that newrev is a strict subset
-			# of oldrev - (would have required a force, but that's allowed).
-			# So, we can't simply say rev-list $oldrev..$newrev.  Instead
-			# we find the common base of the two revs and list from there
-			baserev=$(git-merge-base $oldrev $newrev)
-
-			# Commit with a parent
-			for rev in $(git-rev-list $newrev --not $baserev --all)
-			do
-				revtype=$(git-cat-file -t "$rev")
-				echo "       via  $rev ($revtype)"
-			done
-			if [ "$baserev" = "$oldrev" ]; then
-				echo "      from  $oldrev ($oldrev_type)"
-			else
-				echo "  based on  $baserev"
-				echo "      from  $oldrev ($oldrev_type)"
-				echo ""
-				echo "This ref update crossed a branch point; i.e. the old rev is not a strict subset"
-				echo "of the new rev.  This occurs, when you --force push a change in a situation"
-				echo "like this:"
-				echo ""
-				echo " * -- * -- B -- O -- O -- O ($oldrev)"
-				echo "            \\"
-				echo "             N -- N -- N ($newrev)"
-				echo ""
-				echo "Therefore, we assume that you've already had alert emails for all of the O"
-				echo "revisions, and now give you all the revisions in the N branch from the common"
-				echo "base, B ($baserev), up to the new revision."
-			fi
-			echo ""
-			echo $LOGBEGIN
-			git log $newrev --not $baserev --all
-			echo $LOGEND
-			echo ""
-			echo "Diffstat:"
-			git-diff-tree --no-color --stat -M -C --find-copies-harder $baserev..$newrev
-		fi
-		;;
-	"annotated tag")
-		# Should we allow changes to annotated tags?
-		if expr "$oldrev" : '0*$' >/dev/null
-		then
-			# If the old reference is "0000..0000" then this is a new atag
-			# and so oldrev is not valid
-			echo "        to  $newrev ($newrev_type)"
-		else
-			echo "        to  $newrev ($newrev_type)"
-			echo "      from  $oldrev"
-		fi
-
-		# If this tag succeeds another, then show which tag it replaces
-		prevtag=$(git describe --abbrev=0 $newrev^ 2>/dev/null)
-		if [ -n "$prevtag" ]; then
-			echo "  replaces  $prevtag"
-		fi
-
-		# Read the tag details
-		eval $(git cat-file tag $newrev | \
-			sed -n '4s/tagger \([^>]*>\)[^0-9]*\([0-9]*\).*/tagger="\1" ts="\2"/p')
-		tagged=$(date --date="1970-01-01 00:00:00 +0000 $ts seconds" +"$DATEFORMAT")
-
-		echo " tagged by  $tagger"
-		echo "        on  $tagged"
-
-		echo ""
-		echo $LOGBEGIN
-		echo ""
-
-		if [ -n "$prevtag" ]; then
-			git rev-list --pretty=short "$prevtag..$newrev" | git shortlog
-		else
-			git rev-list --pretty=short $newrev | git shortlog
-		fi
-
-		echo $LOGEND
-		echo ""
-		;;
-	*)
-		# By default, unannotated tags aren't allowed in; if
-		# they are though, it's debatable whether we would even want an
-		# email to be generated; however, I don't want to add another config
-		# option just for that.
-		#
-		# Unannotated tags are more about marking a point than releasing
-		# a version; therefore we don't do the shortlog summary that we
-		# do for annotated tags above - we simply show that the point has
-		# been marked, and print the log message for the marked point for
-		# reference purposes
-		#
-		# Note this section also catches any other reference type (although
-		# there aren't any) and deals with them in the same way.
-		if expr "$oldrev" : '0*$' >/dev/null
-		then
-			# If the old reference is "0000..0000" then this is a new tag
-			# and so oldrev is not valid
-			echo "  as a new  $refname_type"
-			echo "        to  $newrev ($newrev_type)"
-		else
-			echo "        to  $newrev ($newrev_type)"
-			echo "      from  $oldrev"
-		fi
-		echo ""
-		echo $LOGBEGIN
-		git-show --no-color --root -s $newrev
-		echo $LOGEND
-		echo ""
-		;;
-esac
-
-# Footer
-cat <<-EOF
-
-hooks/update
----
-Git Source Code Management System
-$0 $1 \\
-  $2 \\
-  $3
-EOF
-#) | cat >&2
-) | /usr/sbin/sendmail -t
-
 # --- Finished
 exit 0
-- 
1.5.1.rc1.28.gedbf0
Junio C Hamano· Mar 24, 2007, 01:09 UTC · re: Andy Parkins · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

Andy Parkins <andyparkins@gmail.com> writes:
Show 8 quoted lines
> Now that we have a post-receive hook; the update hook's only job is to
> decide is a particular update is allowed or not.
>
> This example hook removes all of the functionality that should now
> rightly be done by the post-receive hook.  In particular: the generation
> of notification emails.
>
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>

I was quite impressed by seeing what Shawn did with his 'continuous' stuff, not the way it is implemented, but the way it was presented as "you can do this to use it from your hook script".

You know what? I am very tempted to take this patch, while dropping the other one. Well, dropping is probably not quite accurate, because being a nice person (and I am good looking, too ;-), I would probably end up creating "contrib/mailhook/" hierarchy and stash the contents of your second patch there myself.

I think I'd better let fancier hooks live in contrib/examples hierarchy for people to pick and choose, and keep the default templates/ directory lean and clean.

There is a small detail of how users who use prepackaged git would get rich library of example hooks from, but that is something better left to distro people; that way I do not have to worry about them too much, and it would also make it crystal clear that these are just examples.

The thing is, not many people are interested in sending e-mail out from post- any hooks (I don't do so, Linus doesn't either), and there is no strong justifiation to give e-mail sending users any preferential treatment and penalize others by copying rather huge hook scripts from templates/ that they are not going to ever use.

Linus Torvalds· Mar 24, 2007, 03:23 UTC · re: Junio C Hamano · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On Fri, 23 Mar 2007, Junio C Hamano wrote:
>
>	.. because being a nice person (and I am good looking,
> too ;-)
Snif. My boy has all grown up.
There is nothing more I can teach you, grasshopper.
		Linus
Shawn O. Pearce· Mar 24, 2007, 03:28 UTC · re: Junio C Hamano · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

Junio C Hamano <junkio@cox.net> wrote:
> I think I'd better let fancier hooks live in contrib/examples
> hierarchy for people to pick and choose, and keep the default
> templates/ directory lean and clean.

I agree. Which is why I submitted my little continuous integration server as contrib/continuous and not as a hook in templates.

;-)
-- 
Shawn.
Andy Parkins· Mar 24, 2007, 08:14 UTC · re: Junio C Hamano · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On Saturday 2007, March 24, Junio C Hamano wrote:
Show 6 quoted lines
> You know what?  I am very tempted to take this patch, while
> dropping the other one.  Well, dropping is probably not quite
> accurate, because being a nice person (and I am good looking,
> too ;-), I would probably end up creating "contrib/mailhook/"
> hierarchy and stash the contents of your second patch there
> myself.

I'm inclined to agree. This one is obviously good because the hook script gets simpler.

> I think I'd better let fancier hooks live in contrib/examples
> hierarchy for people to pick and choose, and keep the default
> templates/ directory lean and clean.

I really wasn't trying to be fancy; just complete. I hope that with this script that every possible type of reference update is caught and reported correctly. Unfortunately that makes the script large and uncomfortable to put in a template directory; particularly as it's only really useful in a bare repository so every user wouldn't want to have it. (incidentally, I've long thought that there should be two template directories - one for bare and one for working)

> The thing is, not many people are interested in sending e-mail
> out from post- any hooks (I don't do so, Linus doesn't either),

I'm not sure that two people is a representative sample for the "not many people are interested" case. The times I think people will use it commonly is for internal projects. I have this script activated on every project I work on, but not one of them is open source. They all report to the interested parties so they know when to update their own repositories (or for a manager to see when a release is made).

Having said all that; I don't like the idea of putting this in the standard git templates; but not (primarily) for the reason of size. The problem, I think, is that of bug fixes. At the moment, I copy the script from the templates directory to a projects/git/ directory, then for each repository within that I symbolic link the projects/git/project.git/hooks/post-receive file to the master script. This is still not a good solution because I have to manually copy the script if I ever upgrade git (or more likely a package manager upgrades it), so any bug fixes in the hook script don't get automatically implemented.

So: ideally, what /I/ would like is that git distributes the script in a 
standard location like /usr/share/doc/git/contrib/post-receive-emailer 
with the execute bit already set; that can be easily linked to or 
called from the actual post-receive hook.
Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Theodore Tso· Mar 24, 2007, 10:26 UTC · re: Andy Parkins · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On Sat, Mar 24, 2007 at 08:14:31AM +0000, Andy Parkins wrote:
> So: ideally, what /I/ would like is that git distributes the script in a 
> standard location like /usr/share/doc/git/contrib/post-receive-emailer 
> with the execute bit already set; that can be easily linked to or 
> called from the actual post-receive hook.

I wonder if this is a good idea to do for all or most of the template scripts, so that they can get automatically updated when git is updated, instead of having the problem we had before where the hook script got updated to match changes in git, but ancient repositories would still have the old script.

						- Ted
Junio C Hamano· Mar 24, 2007, 10:41 UTC · re: Theodore Tso · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

Theodore Tso <tytso@mit.edu> writes:
Show 11 quoted lines
> On Sat, Mar 24, 2007 at 08:14:31AM +0000, Andy Parkins wrote:
>> So: ideally, what /I/ would like is that git distributes the script in a 
>> standard location like /usr/share/doc/git/contrib/post-receive-emailer 
>> with the execute bit already set; that can be easily linked to or 
>> called from the actual post-receive hook.
>
> I wonder if this is a good idea to do for all or most of the template
> scripts, so that they can get automatically updated when git is
> updated, instead of having the problem we had before where the hook
> script got updated to match changes in git, but ancient repositories
> would still have the old script.

I do agree that dealing with ancient scripts that casually used implementation details that later versions broke is a problem.

But the recent updates to the mail-hook are backward compatible only in the sense that as long as the user configures it, the new script can mimic old version's behaviour (in other words, it was not backward compatible at all). I think forcing updates to the hooks automatically is worse. I'd rather keep hooks private to repository owner's concern.

While I think it would be great to have a central clearinghouse for people to share and enjoy useful hook collections for various workflows and use cases, I do not necessarily think inside git.git project itself is the best place to do so.

Andy Parkins· Mar 24, 2007, 12:44 UTC · re: Junio C Hamano · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On Saturday 2007, March 24, Junio C Hamano wrote:
Show 6 quoted lines
> But the recent updates to the mail-hook are backward compatible
> only in the sense that as long as the user configures it, the
> new script can mimic old version's behaviour (in other words, it
> was not backward compatible at all).  I think forcing updates to
> the hooks automatically is worse.  I'd rather keep hooks private
> to repository owner's concern.

But the user is still perfectly fine to /copy/ the script into individual repositories; but for those who don't care and just want "the latest and greatest" from whatever git supplies a link to the sample hook seems like a good solution. I'm certainly not suggesting updating the ones in people's repositories automatically; what I'm suggesting is this:

ln -s \
  /usr/doc/git/contrib/post-receive-email
  /var/lib/git/project.git/hooks/post-receive
Or perhaps have the template post-receive hook simply contain
 . /usr/doc/git/contrib/post-receive-email

With the above in place when a user upgrades git with their package manager, and they have enabled the default hook script (which simply calls the one stored in a known location), they get the upgrade without having to think.

> While I think it would be great to have a central clearinghouse
> for people to share and enjoy useful hook collections for
> various workflows and use cases, I do not necessarily think

I agree - filling the place with every hook script that turns up is obviously not sensible. However, this is not a hook collection; nor are their "people", there is just me. Shawn asked if I'd convert the existing update hook to post-receive, that's what I did. Show me these other "hook collections" that are desparately trying to get this apparently coveted position...

> inside git.git project itself is the best place to do so.
Erm, where is the right place then?

I think that git should supply in git.git a default set that do typically wanted things (things like the perfect patch pre-commit hook, the no-unannotated-tags update hook, and of course the email sending hook) that can be enabled with a simple chmod a+x hooks/somescript. All I was doing was supplying a script to fill the post-receive slot.

That all sounds a lot more toys-out-of-pram than I intend; in the end, I'm only trying to fix the bugs that are in old update-hook.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Theodore Tso· Mar 24, 2007, 14:21 UTC · re: Junio C Hamano · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On Sat, Mar 24, 2007 at 03:41:30AM -0700, Junio C Hamano wrote:
> While I think it would be great to have a central clearinghouse
> for people to share and enjoy useful hook collections for
> various workflows and use cases, I do not necessarily think
> inside git.git project itself is the best place to do so.

What are your concernswith having a set of useful hook collections in contrib/hooks, which get installed in /usr/share/git/hooks, or some such? The nice of doing this is that various distro packages will have the hooks installed in standardized places, which means that it becomes easier for people distribute receipes on how to enable various advanced bits of functionality by using 'ln -s /usr/share/git/hooks/FOO .git/hooks/BAR', and it's standardized across distributions.

						- Ted
Francis Moreau· Mar 24, 2007, 14:43 UTC · re: Andy Parkins · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

Hi,
On 3/23/07, Andy Parkins <andyparkins@gmail.com> wrote:
Show 7 quoted lines
> Now that we have a post-receive hook; the update hook's only job is to
> decide is a particular update is allowed or not.
>
> This example hook removes all of the functionality that should now
> rightly be done by the post-receive hook.  In particular: the generation
> of notification emails.
>

I would like to use this hook not for sending update annoucements by emails but rather for keeping those annoucements into files that I could published on the project site for example.

Are there any simple ways to enable this behaviour from your hooks ?
thanks
-- 
Francis
Andy Parkins· Mar 24, 2007, 15:48 UTC · re: Francis Moreau · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On Saturday 2007, March 24, Francis Moreau wrote:
> Are there any simple ways to enable this behaviour from your hooks ?

Yes; have a look near the bottom of the post receive hook (update to come today, so don't use it yet), but you'll see:

 while read oldrev newrev refname
 do
  generate_email $oldrev $newrev $refname | /usr/sbin/sendmail -t
 done
That pipe to send mail could be anything you want, say
 generate_email >> /var/www/update-announcements.txt
Would that suit you?
Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Francis Moreau· Mar 24, 2007, 18:15 UTC · re: Andy Parkins · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On 3/24/07, Andy Parkins <andyparkins@gmail.com> wrote:
Show 18 quoted lines
> On Saturday 2007, March 24, Francis Moreau wrote:
>
> > Are there any simple ways to enable this behaviour from your hooks ?
>
> Yes; have a look near the bottom of the post receive hook (update to
> come today, so don't use it yet), but you'll see:
>
>  while read oldrev newrev refname
>  do
>   generate_email $oldrev $newrev $refname | /usr/sbin/sendmail -t
>  done
>
> That pipe to send mail could be anything you want, say
>
>  generate_email >> /var/www/update-announcements.txt
>
> Would that suit you?
>

yes that almost would do the thing. But instead of hacking the hook, it would be great to have a trivial setup at the begining of the script to choose this config.

Maybe a local config in the repo through the command `git config` could do the job ?

$ git config hook.update.path "/var/www/"

And if the config is to write the message to a file, skip the email stuffs generation (header, foorter...).

thanks
-- 
Francis
Andy Parkins· Mar 25, 2007, 09:11 UTC · re: Francis Moreau · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On Saturday 2007, March 24, Francis Moreau wrote:
> yes that almost would do the thing. But instead of hacking the hook,
> it would be great to have a trivial setup at the begining of the
> script to choose this config.

I'd like Junio's permission before actually doing that; I know he is worried about out-of-control growth of hook scripts and it's already overly large just to do the one job it's got.

Show 7 quoted lines
> Maybe a local config in the repo through the command `git config`
> could do the job ?
>
> $ git config hook.update.path "/var/www/"
>
> And if the config is to write the message to a file, skip the email
> stuffs generation (header, foorter...).

Again; it's not hard to do, and I don't mind adding it, but I don't want to set off Junio's bloat detector. Bear in mind also that in the example you ask for every repo user would need write access to "/var/www"; because the hook script runs as the user performing the push.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
Shawn O. Pearce· Mar 25, 2007, 09:25 UTC · re: Andy Parkins · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

Andy Parkins <andyparkins@gmail.com> wrote:
Show 9 quoted lines
> On Saturday 2007, March 24, Francis Moreau wrote:
> 
> > yes that almost would do the thing. But instead of hacking the hook,
> > it would be great to have a trivial setup at the begining of the
> > script to choose this config.
> 
> I'd like Junio's permission before actually doing that; I know he is 
> worried about out-of-control growth of hook scripts and it's already 
> overly large just to do the one job it's got.
One thought I had today:

The old hooks (update, post-update) were easy to chain if you wanted to run more than one "standard" hook in a repository. Just pass "$@" to each hook excutable, using a small shell-script wrapper that is installed as the actual hook.

The new hooks (pre-receive, post-receive) are not so easy to chain, as their input comes by way of stdin. You'd have to copy the data off to a temporary file, and redirect that into each hook in turn. Annoying.

So I'm kicking around the idea of teaching receive-pack to run hooks in filename order if the hook is actually a subdirectory. Then you can do:

  mkdir .git/hooks/post-receive
  ln -s \
    ~/git/contrib/email/post-receive-head \
    .git/hooks/post-receive/01-head
  ln -s \
    ~/git/contrib/email/post-receive-tag \
    .git/hooks/post-receive/02-tag
  ln -s \
    ~/git/contrib/continuous/post-receive-cinotify \
    .git/hooks/post-receive/10-cinotify

Where this applies to Andy's message that I quoted is the email hooks could be split up to handle different types of refs in each hook, e.g. one for heads and one for tags, and just skip refs that don't apply to that particular hook.

-- 
Shawn.
Francis Moreau· Mar 25, 2007, 14:04 UTC · re: Andy Parkins · lore

Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

On 3/25/07, Andy Parkins <andyparkins@gmail.com> wrote:
Show 6 quoted lines
> Again; it's not hard to do, and I don't mind adding it, but I don't want
> to set off Junio's bloat detector.  Bear in mind also that in the
> example you ask for every repo user would need write access
> to "/var/www"; because the hook script runs as the user performing the
> push.
>

yes it should be fairly easy. But the point is that trivial feature should not imply any modifications IMHO or at least the simplest one: "FILE=<path>".

>From an external point of view, sending the announcement by email is
an extension of generating a message for each update.
-- 
Francis

← back to recent threads