{"thread":{"id":"7364","subject":"[PATCH] update-hook: remove all functionality that should be in hooks/post-receive","startedAt":"2007-03-23T10:21:59Z","lastAt":"2007-03-25T14:04:24Z","messageCount":15,"participants":["Andy Parkins","Junio C Hamano","Linus Torvalds","Shawn O. Pearce","Theodore Tso","Francis Moreau"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"37803","messageId":"200703231022.00189.andyparkins@gmail.com","threadId":"7364","inReplyTo":null,"subject":"[PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-23T10:21:59Z","receivedAt":"2007-03-23T10:21:59Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Now that we have a post-receive hook; the update hook's only job is to\ndecide is a particular update is allowed or not.\n\nThis example hook removes all of the functionality that should now\nrightly be done by the post-receive hook.  In particular: the generation\nof notification emails.\n\nSigned-off-by: Andy Parkins <andyparkins@gmail.com>\n---\nReplacement of functionality removed by this patch with a post-receive hook\nto follow.\n\n templates/hooks--update |  225 +----------------------------------------------\n 1 files changed, 3 insertions(+), 222 deletions(-)\n\ndiff --git a/templates/hooks--update b/templates/hooks--update\nindex 8f6c4fe..638d2d1 100644\n--- a/templates/hooks--update\n+++ b/templates/hooks--update\n@@ -1,36 +1,16 @@\n #!/bin/sh\n #\n-# An example hook script to mail out commit update information.\n-# It can also blocks tags that aren't annotated.\n+# An example hook script to blocks unannotated tags from entering.\n # Called by git-receive-pack with arguments: refname sha1-old sha1-new\n #\n # To enable this hook, make this file executable by \"chmod +x update\".\n #\n # Config\n # ------\n-# hooks.mailinglist\n-#   This is the list that all pushes will go to; leave it blank to not send\n-#   emails frequently.  The log email will list every log entry in full between\n-#   the old ref value and the new ref value.\n-# hooks.announcelist\n-#   This is the list that all pushes of annotated tags will go to.  Leave it\n-#   blank to just use the mailinglist field.  The announce emails list the\n-#   short log summary of the changes since the last annotated tag\n # hooks.allowunannotated\n #   This boolean sets whether unannotated tags will be allowed into the\n #   repository.  By default they won't be.\n #\n-# Notes\n-# -----\n-# All emails have their subjects prefixed with \"[SCM]\" to aid filtering.\n-# All emails include the headers \"X-Git-Refname\", \"X-Git-Oldrev\",\n-# \"X-Git-Newrev\", and \"X-Git-Reftype\" to enable fine tuned filtering and info.\n-\n-# --- Constants\n-EMAILPREFIX=\"[SCM] \"\n-LOGBEGIN=\"- Log -----------------------------------------------------------------\"\n-LOGEND=\"-----------------------------------------------------------------------\"\n-DATEFORMAT=\"%F %R %z\"\n \n # --- Command line\n refname=\"$1\"\n@@ -51,9 +31,6 @@ if [ -z \"$refname\" -o -z \"$oldrev\" -o -z \"$newrev\" ]; then\n fi\n \n # --- Config\n-projectdesc=$(cat $GIT_DIR/description)\n-recipients=$(git-repo-config hooks.mailinglist)\n-announcerecipients=$(git-repo-config hooks.announcelist)\n allowunannotated=$(git-repo-config --bool hooks.allowunannotated)\n \n # --- Check types\n@@ -62,224 +39,28 @@ newrev_type=$(git-cat-file -t $newrev)\n case \"$refname\",\"$newrev_type\" in\n \trefs/tags/*,commit)\n \t\t# un-annotated tag\n-\t\trefname_type=\"tag\"\n \t\tshort_refname=${refname##refs/tags/}\n \t\tif [ \"$allowunannotated\" != \"true\" ]; then\n-\t\t\techo \"*** The un-annotated tag, $short_refname is not allowed in this repository\" >&2\n+\t\t\techo \"*** The un-annotated tag, $short_refname, is not allowed in this repository\" >&2\n \t\t\techo \"*** Use 'git tag [ -a | -s ]' for tags you want to propagate.\" >&2\n \t\t\texit 1\n \t\tfi\n \t\t;;\n \trefs/tags/*,tag)\n \t\t# annotated tag\n-\t\trefname_type=\"annotated tag\"\n-\t\tshort_refname=${refname##refs/tags/}\n-\t\t# change recipients\n-\t\tif [ -n \"$announcerecipients\" ]; then\n-\t\t\trecipients=\"$announcerecipients\"\n-\t\tfi\n \t\t;;\n \trefs/heads/*,commit)\n \t\t# branch\n-\t\trefname_type=\"branch\"\n-\t\tshort_refname=${refname##refs/heads/}\n \t\t;;\n \trefs/remotes/*,commit)\n \t\t# tracking branch\n-\t\trefname_type=\"tracking branch\"\n-\t\tshort_refname=${refname##refs/remotes/}\n-\t\t# Should this even be allowed?\n-\t\techo \"*** Push-update of tracking branch, $refname.  No email generated.\" >&2\n-\t\texit 0\n \t\t;;\n \t*)\n \t\t# Anything else (is there anything else?)\n-\t\techo \"*** Update hook: unknown type of update, \\\"$newrev_type\\\", to ref $refname\" >&2\n+\t\techo \"*** Update hook: unknown type of update to ref $refname of type $newrev_type\" >&2\n \t\texit 1\n \t\t;;\n esac\n \n-# Check if we've got anyone to send to\n-if [ -z \"$recipients\" ]; then\n-\t# If the email isn't sent, then at least give the user some idea of what command\n-\t# would generate the email at a later date\n-\techo \"*** No recipients found - no email will be sent, but the push will continue\" >&2\n-\techo \"*** for $0 $1 $2 $3\" >&2\n-\texit 0\n-fi\n-\n-# --- Email parameters\n-committer=$(git show --pretty=full -s $newrev | grep \"^Commit: \" | sed -e \"s/^Commit: //\")\n-describe=$(git describe $newrev 2>/dev/null)\n-if [ -z \"$describe\" ]; then\n-\tdescribe=$newrev\n-fi\n-\n-# --- Email (all stdout will be the email)\n-(\n-# Generate header\n-cat <<-EOF\n-From: $committer\n-To: $recipients\n-Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname now at $describe\n-X-Git-Refname: $refname\n-X-Git-Reftype: $refname_type\n-X-Git-Oldrev: $oldrev\n-X-Git-Newrev: $newrev\n-\n-Hello,\n-\n-This is an automated email from the git hooks/update script, it was\n-generated because a ref change was pushed to the repository.\n-\n-Updating $refname_type, $short_refname,\n-EOF\n-\n-case \"$refname_type\" in\n-\t\"tracking branch\"|branch)\n-\t\tif expr \"$oldrev\" : '0*$' >/dev/null\n-\t\tthen\n-\t\t\t# If the old reference is \"0000..0000\" then this is a new branch\n-\t\t\t# and so oldrev is not valid\n-\t\t\techo \"  as a new  $refname_type\"\n-\t\t    echo \"        to  $newrev ($newrev_type)\"\n-\t\t\techo \"\"\n-\t\t\techo $LOGBEGIN\n-\t\t\t# This shows all log entries that are not already covered by\n-\t\t\t# another ref - i.e. commits that are now accessible from this\n-\t\t\t# ref that were previously not accessible\n-\t\t\tgit log $newrev --not --all\n-\t\t\techo $LOGEND\n-\t\telse\n-\t\t\t# oldrev is valid\n-\t\t\toldrev_type=$(git-cat-file -t \"$oldrev\")\n-\n-\t\t\t# Now the problem is for cases like this:\n-\t\t\t#   * --- * --- * --- * (oldrev)\n-\t\t\t#          \\\n-\t\t\t#           * --- * --- * (newrev)\n-\t\t\t# i.e. there is no guarantee that newrev is a strict subset\n-\t\t\t# of oldrev - (would have required a force, but that's allowed).\n-\t\t\t# So, we can't simply say rev-list $oldrev..$newrev.  Instead\n-\t\t\t# we find the common base of the two revs and list from there\n-\t\t\tbaserev=$(git-merge-base $oldrev $newrev)\n-\n-\t\t\t# Commit with a parent\n-\t\t\tfor rev in $(git-rev-list $newrev --not $baserev --all)\n-\t\t\tdo\n-\t\t\t\trevtype=$(git-cat-file -t \"$rev\")\n-\t\t\t\techo \"       via  $rev ($revtype)\"\n-\t\t\tdone\n-\t\t\tif [ \"$baserev\" = \"$oldrev\" ]; then\n-\t\t\t\techo \"      from  $oldrev ($oldrev_type)\"\n-\t\t\telse\n-\t\t\t\techo \"  based on  $baserev\"\n-\t\t\t\techo \"      from  $oldrev ($oldrev_type)\"\n-\t\t\t\techo \"\"\n-\t\t\t\techo \"This ref update crossed a branch point; i.e. the old rev is not a strict subset\"\n-\t\t\t\techo \"of the new rev.  This occurs, when you --force push a change in a situation\"\n-\t\t\t\techo \"like this:\"\n-\t\t\t\techo \"\"\n-\t\t\t\techo \" * -- * -- B -- O -- O -- O ($oldrev)\"\n-\t\t\t\techo \"            \\\\\"\n-\t\t\t\techo \"             N -- N -- N ($newrev)\"\n-\t\t\t\techo \"\"\n-\t\t\t\techo \"Therefore, we assume that you've already had alert emails for all of the O\"\n-\t\t\t\techo \"revisions, and now give you all the revisions in the N branch from the common\"\n-\t\t\t\techo \"base, B ($baserev), up to the new revision.\"\n-\t\t\tfi\n-\t\t\techo \"\"\n-\t\t\techo $LOGBEGIN\n-\t\t\tgit log $newrev --not $baserev --all\n-\t\t\techo $LOGEND\n-\t\t\techo \"\"\n-\t\t\techo \"Diffstat:\"\n-\t\t\tgit-diff-tree --no-color --stat -M -C --find-copies-harder $baserev..$newrev\n-\t\tfi\n-\t\t;;\n-\t\"annotated tag\")\n-\t\t# Should we allow changes to annotated tags?\n-\t\tif expr \"$oldrev\" : '0*$' >/dev/null\n-\t\tthen\n-\t\t\t# If the old reference is \"0000..0000\" then this is a new atag\n-\t\t\t# and so oldrev is not valid\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\telse\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\t\techo \"      from  $oldrev\"\n-\t\tfi\n-\n-\t\t# If this tag succeeds another, then show which tag it replaces\n-\t\tprevtag=$(git describe --abbrev=0 $newrev^ 2>/dev/null)\n-\t\tif [ -n \"$prevtag\" ]; then\n-\t\t\techo \"  replaces  $prevtag\"\n-\t\tfi\n-\n-\t\t# Read the tag details\n-\t\teval $(git cat-file tag $newrev | \\\n-\t\t\tsed -n '4s/tagger \\([^>]*>\\)[^0-9]*\\([0-9]*\\).*/tagger=\"\\1\" ts=\"\\2\"/p')\n-\t\ttagged=$(date --date=\"1970-01-01 00:00:00 +0000 $ts seconds\" +\"$DATEFORMAT\")\n-\n-\t\techo \" tagged by  $tagger\"\n-\t\techo \"        on  $tagged\"\n-\n-\t\techo \"\"\n-\t\techo $LOGBEGIN\n-\t\techo \"\"\n-\n-\t\tif [ -n \"$prevtag\" ]; then\n-\t\t\tgit rev-list --pretty=short \"$prevtag..$newrev\" | git shortlog\n-\t\telse\n-\t\t\tgit rev-list --pretty=short $newrev | git shortlog\n-\t\tfi\n-\n-\t\techo $LOGEND\n-\t\techo \"\"\n-\t\t;;\n-\t*)\n-\t\t# By default, unannotated tags aren't allowed in; if\n-\t\t# they are though, it's debatable whether we would even want an\n-\t\t# email to be generated; however, I don't want to add another config\n-\t\t# option just for that.\n-\t\t#\n-\t\t# Unannotated tags are more about marking a point than releasing\n-\t\t# a version; therefore we don't do the shortlog summary that we\n-\t\t# do for annotated tags above - we simply show that the point has\n-\t\t# been marked, and print the log message for the marked point for\n-\t\t# reference purposes\n-\t\t#\n-\t\t# Note this section also catches any other reference type (although\n-\t\t# there aren't any) and deals with them in the same way.\n-\t\tif expr \"$oldrev\" : '0*$' >/dev/null\n-\t\tthen\n-\t\t\t# If the old reference is \"0000..0000\" then this is a new tag\n-\t\t\t# and so oldrev is not valid\n-\t\t\techo \"  as a new  $refname_type\"\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\telse\n-\t\t\techo \"        to  $newrev ($newrev_type)\"\n-\t\t\techo \"      from  $oldrev\"\n-\t\tfi\n-\t\techo \"\"\n-\t\techo $LOGBEGIN\n-\t\tgit-show --no-color --root -s $newrev\n-\t\techo $LOGEND\n-\t\techo \"\"\n-\t\t;;\n-esac\n-\n-# Footer\n-cat <<-EOF\n-\n-hooks/update\n----\n-Git Source Code Management System\n-$0 $1 \\\\\n-  $2 \\\\\n-  $3\n-EOF\n-#) | cat >&2\n-) | /usr/sbin/sendmail -t\n-\n # --- Finished\n exit 0\n-- \n1.5.1.rc1.28.gedbf0\n"},{"id":"37851","messageId":"7v648ro3a3.fsf@assigned-by-dhcp.cox.net","threadId":"7364","inReplyTo":"200703231022.00189.andyparkins@gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-24T01:09:56Z","receivedAt":"2007-03-24T01:09:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> writes:\n\n> Now that we have a post-receive hook; the update hook's only job is to\n> decide is a particular update is allowed or not.\n>\n> This example hook removes all of the functionality that should now\n> rightly be done by the post-receive hook.  In particular: the generation\n> of notification emails.\n>\n> Signed-off-by: Andy Parkins <andyparkins@gmail.com>\n\nI was quite impressed by seeing what Shawn did with his\n'continuous' stuff, not the way it is implemented, but the way\nit was presented as \"you can do this to use it from your hook\nscript\".\n\nYou know what?  I am very tempted to take this patch, while\ndropping the other one.  Well, dropping is probably not quite\naccurate, because being a nice person (and I am good looking,\ntoo ;-), I would probably end up creating \"contrib/mailhook/\"\nhierarchy and stash the contents of your second patch there\nmyself.\n\nI think I'd better let fancier hooks live in contrib/examples\nhierarchy for people to pick and choose, and keep the default\ntemplates/ directory lean and clean.\n\nThere is a small detail of how users who use prepackaged git\nwould get rich library of example hooks from, but that is\nsomething better left to distro people; that way I do not have\nto worry about them too much, and it would also make it crystal\nclear that these are just examples.\n\nThe thing is, not many people are interested in sending e-mail\nout from post- any hooks (I don't do so, Linus doesn't either),\nand there is no strong justifiation to give e-mail sending users\nany preferential treatment and penalize others by copying rather\nhuge hook scripts from templates/ that they are not going to\never use.\n"},{"id":"37852","messageId":"Pine.LNX.4.64.0703232023150.6730@woody.linux-foundation.org","threadId":"7364","inReplyTo":"7v648ro3a3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-24T03:23:54Z","receivedAt":"2007-03-24T03:23:54Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 23 Mar 2007, Junio C Hamano wrote:\n>\n>\t.. because being a nice person (and I am good looking,\n> too ;-)\n\nSnif. My boy has all grown up.\n\nThere is nothing more I can teach you, grasshopper.\n\n\t\tLinus\n"},{"id":"37853","messageId":"20070324032802.GA25863@spearce.org","threadId":"7364","inReplyTo":"7v648ro3a3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-24T03:28:03Z","receivedAt":"2007-03-24T03:28:03Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> I think I'd better let fancier hooks live in contrib/examples\n> hierarchy for people to pick and choose, and keep the default\n> templates/ directory lean and clean.\n\nI agree.  Which is why I submitted my little continuous integration\nserver as contrib/continuous and not as a hook in templates.\n\n;-)\n\n-- \nShawn.\n"},{"id":"37866","messageId":"200703240814.35525.andyparkins@gmail.com","threadId":"7364","inReplyTo":"7v648ro3a3.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-24T08:14:31Z","receivedAt":"2007-03-24T08:14:31Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, March 24, Junio C Hamano wrote:\n\n> You know what?  I am very tempted to take this patch, while\n> dropping the other one.  Well, dropping is probably not quite\n> accurate, because being a nice person (and I am good looking,\n> too ;-), I would probably end up creating \"contrib/mailhook/\"\n> hierarchy and stash the contents of your second patch there\n> myself.\n\nI'm inclined to agree.  This one is obviously good because the hook \nscript gets simpler.\n\n> I think I'd better let fancier hooks live in contrib/examples\n> hierarchy for people to pick and choose, and keep the default\n> templates/ directory lean and clean.\n\nI really wasn't trying to be fancy; just complete.  I hope that with \nthis script that every possible type of reference update is caught and \nreported correctly.  Unfortunately that makes the script large and \nuncomfortable to put in a template directory; particularly as it's only \nreally useful in a bare repository so every user wouldn't want to have \nit.  (incidentally, I've long thought that there should be two template \ndirectories - one for bare and one for working)\n\n> The thing is, not many people are interested in sending e-mail\n> out from post- any hooks (I don't do so, Linus doesn't either),\n\nI'm not sure that two people is a representative sample for the \"not \nmany people are interested\" case.  The times I think people will use it \ncommonly is for internal projects.  I have this script activated on \nevery project I work on, but not one of them is open source.  They all \nreport to the interested parties so they know when to update their own \nrepositories (or for a manager to see when a release is made).\n\nHaving said all that; I don't like the idea of putting this in the \nstandard git templates; but not (primarily) for the reason of size.  \nThe problem, I think, is that of bug fixes.  At the moment, I copy the \nscript from the templates directory to a projects/git/ directory, then \nfor each repository within that I symbolic link the \nprojects/git/project.git/hooks/post-receive file to the master script. \nThis is still not a good solution because I have to manually copy the \nscript if I ever upgrade git (or more likely a package manager upgrades \nit), so any bug fixes in the hook script don't get automatically \nimplemented.\n\nSo: ideally, what /I/ would like is that git distributes the script in a \nstandard location like /usr/share/doc/git/contrib/post-receive-emailer \nwith the execute bit already set; that can be easily linked to or \ncalled from the actual post-receive hook.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37871","messageId":"20070324102652.GA15474@thunk.org","threadId":"7364","inReplyTo":"200703240814.35525.andyparkins@gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-03-24T10:26:52Z","receivedAt":"2007-03-24T10:26:52Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Mar 24, 2007 at 08:14:31AM +0000, Andy Parkins wrote:\n> So: ideally, what /I/ would like is that git distributes the script in a \n> standard location like /usr/share/doc/git/contrib/post-receive-emailer \n> with the execute bit already set; that can be easily linked to or \n> called from the actual post-receive hook.\n\nI wonder if this is a good idea to do for all or most of the template\nscripts, so that they can get automatically updated when git is\nupdated, instead of having the problem we had before where the hook\nscript got updated to match changes in git, but ancient repositories\nwould still have the old script.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"37872","messageId":"7vodmikjol.fsf@assigned-by-dhcp.cox.net","threadId":"7364","inReplyTo":"20070324102652.GA15474@thunk.org","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-24T10:41:30Z","receivedAt":"2007-03-24T10:41:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso <tytso@mit.edu> writes:\n\n> On Sat, Mar 24, 2007 at 08:14:31AM +0000, Andy Parkins wrote:\n>> So: ideally, what /I/ would like is that git distributes the script in a \n>> standard location like /usr/share/doc/git/contrib/post-receive-emailer \n>> with the execute bit already set; that can be easily linked to or \n>> called from the actual post-receive hook.\n>\n> I wonder if this is a good idea to do for all or most of the template\n> scripts, so that they can get automatically updated when git is\n> updated, instead of having the problem we had before where the hook\n> script got updated to match changes in git, but ancient repositories\n> would still have the old script.\n\nI do agree that dealing with ancient scripts that casually used\nimplementation details that later versions broke is a problem.\n\nBut the recent updates to the mail-hook are backward compatible\nonly in the sense that as long as the user configures it, the\nnew script can mimic old version's behaviour (in other words, it\nwas not backward compatible at all).  I think forcing updates to\nthe hooks automatically is worse.  I'd rather keep hooks private\nto repository owner's concern.\n\nWhile I think it would be great to have a central clearinghouse\nfor people to share and enjoy useful hook collections for\nvarious workflows and use cases, I do not necessarily think\ninside git.git project itself is the best place to do so.\n"},{"id":"37878","messageId":"200703241244.23151.andyparkins@gmail.com","threadId":"7364","inReplyTo":"7vodmikjol.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-24T12:44:21Z","receivedAt":"2007-03-24T12:44:21Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, March 24, Junio C Hamano wrote:\n\n> But the recent updates to the mail-hook are backward compatible\n> only in the sense that as long as the user configures it, the\n> new script can mimic old version's behaviour (in other words, it\n> was not backward compatible at all).  I think forcing updates to\n> the hooks automatically is worse.  I'd rather keep hooks private\n> to repository owner's concern.\n\nBut the user is still perfectly fine to /copy/ the script into \nindividual repositories; but for those who don't care and just \nwant \"the latest and greatest\" from whatever git supplies a link to the \nsample hook seems like a good solution.  I'm certainly not suggesting \nupdating the ones in people's repositories automatically; what I'm \nsuggesting is this:\n\nln -s \\\n  /usr/doc/git/contrib/post-receive-email\n  /var/lib/git/project.git/hooks/post-receive\n\nOr perhaps have the template post-receive hook simply contain\n\n . /usr/doc/git/contrib/post-receive-email\n\nWith the above in place when a user upgrades git with their package \nmanager, and they have enabled the default hook script (which simply \ncalls the one stored in a known location), they get the upgrade without \nhaving to think.\n\n> While I think it would be great to have a central clearinghouse\n> for people to share and enjoy useful hook collections for\n> various workflows and use cases, I do not necessarily think\n\nI agree - filling the place with every hook script that turns up is \nobviously not sensible.  However, this is not a hook collection; nor \nare their \"people\", there is just me.  Shawn asked if I'd convert the \nexisting update hook to post-receive, that's what I did.  Show me these \nother \"hook collections\" that are desparately trying to get this \napparently coveted position...\n\n> inside git.git project itself is the best place to do so.\n\nErm, where is the right place then?\n\nI think that git should supply in git.git a default set that do \ntypically wanted things (things like the perfect patch pre-commit hook, \nthe no-unannotated-tags update hook, and of course the email sending \nhook) that can be enabled with a simple chmod a+x hooks/somescript.  \nAll I was doing was supplying a script to fill the post-receive slot.\n\nThat all sounds a lot more toys-out-of-pram than I intend; in the end, \nI'm only trying to fix the bugs that are in old update-hook.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37879","messageId":"20070324142104.GA31791@thunk.org","threadId":"7364","inReplyTo":"7vodmikjol.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-03-24T14:21:04Z","receivedAt":"2007-03-24T14:21:04Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Mar 24, 2007 at 03:41:30AM -0700, Junio C Hamano wrote:\n> While I think it would be great to have a central clearinghouse\n> for people to share and enjoy useful hook collections for\n> various workflows and use cases, I do not necessarily think\n> inside git.git project itself is the best place to do so.\n\nWhat are your concernswith having a set of useful hook collections in\ncontrib/hooks, which get installed in /usr/share/git/hooks, or some\nsuch?  The nice of doing this is that various distro packages will\nhave the hooks installed in standardized places, which means that it\nbecomes easier for people distribute receipes on how to enable various\nadvanced bits of functionality by using 'ln -s /usr/share/git/hooks/FOO\n.git/hooks/BAR', and it's standardized across distributions.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"37881","messageId":"38b2ab8a0703240743t3ca2b091w12072046ee03dd5@mail.gmail.com","threadId":"7364","inReplyTo":"200703231022.00189.andyparkins@gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-03-24T14:43:02Z","receivedAt":"2007-03-24T14:43:02Z","isPatch":true,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Hi,\n\nOn 3/23/07, Andy Parkins <andyparkins@gmail.com> wrote:\n> Now that we have a post-receive hook; the update hook's only job is to\n> decide is a particular update is allowed or not.\n>\n> This example hook removes all of the functionality that should now\n> rightly be done by the post-receive hook.  In particular: the generation\n> of notification emails.\n>\n\nI would like to use this hook not for sending update annoucements by\nemails but rather for keeping those annoucements into files that I\ncould published on the project site for example.\n\nAre there any simple ways to enable this behaviour from your hooks ?\n\nthanks\n-- \nFrancis\n"},{"id":"37884","messageId":"200703241548.13775.andyparkins@gmail.com","threadId":"7364","inReplyTo":"38b2ab8a0703240743t3ca2b091w12072046ee03dd5@mail.gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-24T15:48:10Z","receivedAt":"2007-03-24T15:48:10Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, March 24, Francis Moreau wrote:\n\n> Are there any simple ways to enable this behaviour from your hooks ?\n\nYes; have a look near the bottom of the post receive hook (update to \ncome today, so don't use it yet), but you'll see:\n\n while read oldrev newrev refname\n do\n  generate_email $oldrev $newrev $refname | /usr/sbin/sendmail -t\n done\n\nThat pipe to send mail could be anything you want, say\n\n generate_email >> /var/www/update-announcements.txt\n\nWould that suit you?\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37889","messageId":"38b2ab8a0703241115q39dc298clb15357268288b49e@mail.gmail.com","threadId":"7364","inReplyTo":"200703241548.13775.andyparkins@gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-03-24T18:15:50Z","receivedAt":"2007-03-24T18:15:50Z","isPatch":true,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"On 3/24/07, Andy Parkins <andyparkins@gmail.com> wrote:\n> On Saturday 2007, March 24, Francis Moreau wrote:\n>\n> > Are there any simple ways to enable this behaviour from your hooks ?\n>\n> Yes; have a look near the bottom of the post receive hook (update to\n> come today, so don't use it yet), but you'll see:\n>\n>  while read oldrev newrev refname\n>  do\n>   generate_email $oldrev $newrev $refname | /usr/sbin/sendmail -t\n>  done\n>\n> That pipe to send mail could be anything you want, say\n>\n>  generate_email >> /var/www/update-announcements.txt\n>\n> Would that suit you?\n>\n\nyes that almost would do the thing. But instead of hacking the hook,\nit would be great to have a trivial setup at the begining of the\nscript to choose this config.\n\nMaybe a local config in the repo through the command `git config`\ncould do the job ?\n\n$ git config hook.update.path \"/var/www/\"\n\nAnd if the config is to write the message to a file, skip the email\nstuffs generation (header, foorter...).\n\nthanks\n-- \nFrancis\n"},{"id":"37924","messageId":"200703251011.53712.andyparkins@gmail.com","threadId":"7364","inReplyTo":"38b2ab8a0703241115q39dc298clb15357268288b49e@mail.gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-25T09:11:51Z","receivedAt":"2007-03-25T09:11:51Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, March 24, Francis Moreau wrote:\n\n> yes that almost would do the thing. But instead of hacking the hook,\n> it would be great to have a trivial setup at the begining of the\n> script to choose this config.\n\nI'd like Junio's permission before actually doing that; I know he is \nworried about out-of-control growth of hook scripts and it's already \noverly large just to do the one job it's got.\n\n> Maybe a local config in the repo through the command `git config`\n> could do the job ?\n>\n> $ git config hook.update.path \"/var/www/\"\n>\n> And if the config is to write the message to a file, skip the email\n> stuffs generation (header, foorter...).\n\nAgain; it's not hard to do, and I don't mind adding it, but I don't want \nto set off Junio's bloat detector.  Bear in mind also that in the \nexample you ask for every repo user would need write access \nto \"/var/www\"; because the hook script runs as the user performing the \npush.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"37926","messageId":"20070325092530.GI25863@spearce.org","threadId":"7364","inReplyTo":"200703251011.53712.andyparkins@gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-03-25T09:25:31Z","receivedAt":"2007-03-25T09:25:31Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins <andyparkins@gmail.com> wrote:\n> On Saturday 2007, March 24, Francis Moreau wrote:\n> \n> > yes that almost would do the thing. But instead of hacking the hook,\n> > it would be great to have a trivial setup at the begining of the\n> > script to choose this config.\n> \n> I'd like Junio's permission before actually doing that; I know he is \n> worried about out-of-control growth of hook scripts and it's already \n> overly large just to do the one job it's got.\n\nOne thought I had today:\n\nThe old hooks (update, post-update) were easy to chain if you wanted\nto run more than one \"standard\" hook in a repository.  Just pass\n\"$@\" to each hook excutable, using a small shell-script wrapper\nthat is installed as the actual hook.\n\nThe new hooks (pre-receive, post-receive) are not so easy to chain,\nas their input comes by way of stdin.  You'd have to copy the\ndata off to a temporary file, and redirect that into each hook in\nturn.  Annoying.\n\nSo I'm kicking around the idea of teaching receive-pack to run\nhooks in filename order if the hook is actually a subdirectory.\nThen you can do:\n\n  mkdir .git/hooks/post-receive\n  ln -s \\\n    ~/git/contrib/email/post-receive-head \\\n    .git/hooks/post-receive/01-head\n  ln -s \\\n    ~/git/contrib/email/post-receive-tag \\\n    .git/hooks/post-receive/02-tag\n  ln -s \\\n    ~/git/contrib/continuous/post-receive-cinotify \\\n    .git/hooks/post-receive/10-cinotify\n\nWhere this applies to Andy's message that I quoted is the email\nhooks could be split up to handle different types of refs in each\nhook, e.g. one for heads and one for tags, and just skip refs that\ndon't apply to that particular hook.\n\n-- \nShawn.\n"},{"id":"37935","messageId":"38b2ab8a0703250704y54a93b0bpd109de9d6f7d809b@mail.gmail.com","threadId":"7364","inReplyTo":"200703251011.53712.andyparkins@gmail.com","subject":"Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2007-03-25T14:04:24Z","receivedAt":"2007-03-25T14:04:24Z","isPatch":true,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"On 3/25/07, Andy Parkins <andyparkins@gmail.com> wrote:\n> Again; it's not hard to do, and I don't mind adding it, but I don't want\n> to set off Junio's bloat detector.  Bear in mind also that in the\n> example you ask for every repo user would need write access\n> to \"/var/www\"; because the hook script runs as the user performing the\n> push.\n>\n\nyes it should be fairly easy. But the point is that trivial feature\nshould not imply any modifications IMHO or at least the simplest one:\n\"FILE=<path>\".\n\n>From an external point of view, sending the announcement by email is\nan extension of generating a message for each update.\n-- \nFrancis\n"}]}