{"thread":{"id":"10683","subject":"[PATCH] contrib/hooks/post-receive-email: reformat to wrap comments at 76 chars","startedAt":"2007-11-06T13:48:34Z","lastAt":"2007-11-06T13:48:34Z","messageCount":1,"participants":["Gerrit Pape"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"58542","messageId":"20071106134834.24314.qmail@c81ecd7fc93275.315fe32.mid.smarden.org","threadId":"10683","inReplyTo":null,"subject":"[PATCH] contrib/hooks/post-receive-email: reformat to wrap comments at 76 chars","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-11-06T13:48:34Z","receivedAt":"2007-11-06T13:48:34Z","isPatch":true,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"Signed-off-by: Gerrit Pape <pape@smarden.org>\n---\n contrib/hooks/post-receive-email |  199 ++++++++++++++++++++------------------\n 1 files changed, 107 insertions(+), 92 deletions(-)\n\ndiff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email\nindex 379cedc..9b9a977 100644\n--- a/contrib/hooks/post-receive-email\n+++ b/contrib/hooks/post-receive-email\n@@ -2,24 +2,26 @@\n #\n # Copyright (c) 2007 Andy Parkins\n #\n-# An example hook script to mail out commit update information.  This hook sends emails\n-# listing new revisions to the repository introduced by the change being reported.  The\n-# rule is that (for branch updates) each commit will appear on one email and one email\n-# only.\n+# An example hook script to mail out commit update information.  This hook\n+# sends emails listing new revisions to the repository introduced by the\n+# change being reported.  The rule is that (for branch updates) each commit\n+# will appear on one email and one email only.\n #\n-# This hook is stored in the contrib/hooks directory.  Your distribution will have put\n-# this somewhere standard.  You should make this script executable then link to it in\n-# the repository you would like to use it in.  For example, on debian the hook is stored\n-# in /usr/share/doc/git-core/contrib/hooks/post-receive-email:\n+# This hook is stored in the contrib/hooks directory.  Your distribution\n+# will have put this somewhere standard.  You should make this script\n+# executable then link to it in the repository you would like to use it in.\n+# For example, on debian the hook is stored in\n+# /usr/share/doc/git-core/contrib/hooks/post-receive-email:\n #\n #  chmod a+x post-receive-email\n #  cd /path/to/your/repository.git\n #  ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive\n #\n-# This hook script assumes it is enabled on the central repository of a project, with\n-# all users pushing only to it and not between each other.  It will still work if you\n-# don't operate in that style, but it would become possible for the email to be from\n-# someone other than the person doing the push.\n+# This hook script assumes it is enabled on the central repository of a\n+# project, with all users pushing only to it and not between each other.  It\n+# will still work if you don't operate in that style, but it would become\n+# possible for the email to be from someone other than the person doing the\n+# push.\n #\n # Config\n # ------\n@@ -28,11 +30,11 @@\n #   emails for every ref update.\n # hooks.announcelist\n #   This is the list that all pushes of annotated tags will go to.  Leave it\n-#   blank to default to the mailinglist field.  The announce emails lists the\n-#   short log summary of the changes since the last annotated tag.\n+#   blank to default to the mailinglist field.  The announce emails lists\n+#   the short log summary of the changes since the last annotated tag.\n # hooks.envelopesender\n-#   If set then the -f option is passed to sendmail to allow the envelope sender\n-#   address to be set\n+#   If set then the -f option is passed to sendmail to allow the envelope\n+#   sender address to be set\n #\n # Notes\n # -----\n@@ -49,8 +51,8 @@\n # this is and calls the appropriate body-generation routine after outputting\n # the common header\n #\n-# Note this function doesn't actually generate any email output, that is taken\n-# care of by the functions it calls:\n+# Note this function doesn't actually generate any email output, that is\n+# taken care of by the functions it calls:\n #  - generate_email_header\n #  - generate_create_XXXX_email\n #  - generate_update_XXXX_email\n@@ -225,8 +227,9 @@ generate_create_branch_email()\n \techo $LOGBEGIN\n \t# This shows all log entries that are not already covered by\n \t# another ref - i.e. commits that are now accessible from this\n-\t# ref that were previously not accessible (see generate_update_branch_email\n-\t# for the explanation of this command)\n+\t# ref that were previously not accessible\n+\t# (see generate_update_branch_email for the explanation of this\n+\t# command)\n \tgit rev-parse --not --branches | grep -v $(git rev-parse $refname) |\n \tgit rev-list --pretty --stdin $newrev\n \techo $LOGEND\n@@ -254,9 +257,10 @@ generate_update_branch_email()\n \t#\n \t#  git-rev-list N ^O ^X ^N\n \t#\n-\t# So, we need to build up the list more carefully.  git-rev-parse will\n-\t# generate a list of revs that may be fed into git-rev-list.  We can get\n-\t# it to make the \"--not --all\" part and then filter out the \"^N\" with:\n+\t# So, we need to build up the list more carefully.  git-rev-parse\n+\t# will generate a list of revs that may be fed into git-rev-list.\n+\t# We can get it to make the \"--not --all\" part and then filter out\n+\t# the \"^N\" with:\n \t#\n \t#  git-rev-parse --not --all | grep -v N\n \t#\n@@ -266,16 +270,17 @@ generate_update_branch_email()\n \t#  git-rev-list N ^O ^X\n \t#\n \t# This leaves a problem when someone else updates the repository\n-\t# while this script is running.  Their new value of the ref we're working\n-\t# on would be included in the \"--not --all\" output; and as our $newrev\n-\t# would be an ancestor of that commit, it would exclude all of our\n-\t# commits.  What we really want is to exclude the current value of\n-\t# $refname from the --not list, rather than N itself.  So:\n+\t# while this script is running.  Their new value of the ref we're\n+\t# working on would be included in the \"--not --all\" output; and as\n+\t# our $newrev would be an ancestor of that commit, it would exclude\n+\t# all of our commits.  What we really want is to exclude the current\n+\t# value of $refname from the --not list, rather than N itself.  So:\n \t#\n \t#  git-rev-parse --not --all | grep -v $(git-rev-parse $refname)\n \t#\n-\t# Get's us to something pretty safe (apart from the small time between\n-\t# refname being read, and git-rev-parse running - for that, I give up)\n+\t# Get's us to something pretty safe (apart from the small time\n+\t# between refname being read, and git-rev-parse running - for that,\n+\t# I give up)\n \t#\n \t#\n \t# Next problem, consider this:\n@@ -283,18 +288,18 @@ generate_update_branch_email()\n \t#          \\\n \t#           * --- X --- * --- N ($newrev)\n \t#\n-\t# That is to say, there is no guarantee that oldrev is a strict subset of\n-\t# newrev (it would have required a --force, but that's allowed).  So, we\n-\t# can't simply say rev-list $oldrev..$newrev.  Instead we find the common\n-\t# base of the two revs and list from there.\n+\t# That is to say, there is no guarantee that oldrev is a strict\n+\t# subset of newrev (it would have required a --force, but that's\n+\t# allowed).  So, we can't simply say rev-list $oldrev..$newrev.\n+\t# Instead we find the common base of the two revs and list from\n+\t# there.\n \t#\n-\t# As above, we need to take into account the presence of X; if another\n-\t# branch is already in the repository and points at some of the revisions\n-\t# that we are about to output - we don't want them.  The solution is as\n-\t# before: git-rev-parse output filtered.\n+\t# As above, we need to take into account the presence of X; if\n+\t# another branch is already in the repository and points at some of\n+\t# the revisions that we are about to output - we don't want them.\n+\t# The solution is as before: git-rev-parse output filtered.\n \t#\n-\t# Finally, tags:\n-\t#   1 --- 2 --- O --- T --- 3 --- 4 --- N\n+\t# Finally, tags: 1 --- 2 --- O --- T --- 3 --- 4 --- N\n \t#\n \t# Tags pushed into the repository generate nice shortlog emails that\n \t# summarise the commits between them and the previous tag.  However,\n@@ -302,13 +307,14 @@ generate_update_branch_email()\n \t# for a branch update.  Therefore we still want to output revisions\n \t# that have been output on a tag email.\n \t#\n-\t# Luckily, git-rev-parse includes just the tool.  Instead of using \"--all\"\n-\t# we use \"--branches\"; this has the added benefit that \"remotes/\" will\n-\t# be ignored as well.\n-\n-\t# List all of the revisions that were removed by this update, in a fast forward\n-\t# update, this list will be empty, because rev-list O ^N is empty.  For a non\n-\t# fast forward, O ^N is the list of removed revisions\n+\t# Luckily, git-rev-parse includes just the tool.  Instead of using\n+\t# \"--all\" we use \"--branches\"; this has the added benefit that\n+\t# \"remotes/\" will be ignored as well.\n+\n+\t# List all of the revisions that were removed by this update, in a\n+\t# fast forward update, this list will be empty, because rev-list O\n+\t# ^N is empty.  For a non fast forward, O ^N is the list of removed\n+\t# revisions\n \tfast_forward=\"\"\n \trev=\"\"\n \tfor rev in $(git rev-list $newrev..$oldrev)\n@@ -321,10 +327,10 @@ generate_update_branch_email()\n \tfi\n \n \t# List all the revisions from baserev to newrev in a kind of\n-\t# \"table-of-contents\"; note this list can include revisions that have\n-\t# already had notification emails and is present to show the full detail\n-\t# of the change from rolling back the old revision to the base revision and\n-\t# then forward to the new revision\n+\t# \"table-of-contents\"; note this list can include revisions that\n+\t# have already had notification emails and is present to show the\n+\t# full detail of the change from rolling back the old revision to\n+\t# the base revision and then forward to the new revision\n \tfor rev in $(git rev-list $oldrev..$newrev)\n \tdo\n \t\trevtype=$(git cat-file -t \"$rev\")\n@@ -334,19 +340,20 @@ generate_update_branch_email()\n \tif [ \"$fast_forward\" ]; then\n \t\techo \"      from  $oldrev ($oldrev_type)\"\n \telse\n-\t\t#  1. Existing revisions were removed.  In this case newrev is a\n-\t\t#     subset of oldrev - this is the reverse of a fast-forward,\n-\t\t#     a rewind\n-\t\t#  2. New revisions were added on top of an old revision, this is\n-\t\t#     a rewind and addition.\n+\t\t#  1. Existing revisions were removed.  In this case newrev\n+\t\t#     is a subset of oldrev - this is the reverse of a\n+\t\t#     fast-forward, a rewind\n+\t\t#  2. New revisions were added on top of an old revision,\n+\t\t#     this is a rewind and addition.\n \n-\t\t# (1) certainly happened, (2) possibly.  When (2) hasn't happened,\n-\t\t# we set a flag to indicate that no log printout is required.\n+\t\t# (1) certainly happened, (2) possibly.  When (2) hasn't\n+\t\t# happened, we set a flag to indicate that no log printout\n+\t\t# is required.\n \n \t\techo \"\"\n \n-\t\t# Find the common ancestor of the old and new revisions and compare\n-\t\t# it with newrev\n+\t\t# Find the common ancestor of the old and new revisions and\n+\t\t# compare it with newrev\n \t\tbaserev=$(git merge-base $oldrev $newrev)\n \t\trewind_only=\"\"\n \t\tif [ \"$baserev\" = \"$newrev\" ]; then\n@@ -387,21 +394,22 @@ generate_update_branch_email()\n \t\tgit rev-parse --not --branches | grep -v $(git rev-parse $refname) |\n \t\tgit rev-list --pretty --stdin $oldrev..$newrev\n \n-\t\t# XXX: Need a way of detecting whether git rev-list actually outputted\n-\t\t# anything, so that we can issue a \"no new revisions added by this\n-\t\t# update\" message\n+\t\t# XXX: Need a way of detecting whether git rev-list actually\n+\t\t# outputted anything, so that we can issue a \"no new\n+\t\t# revisions added by this update\" message\n \n \t\techo $LOGEND\n \telse\n \t\techo \"No new revisions were added by this update.\"\n \tfi\n \n-\t# The diffstat is shown from the old revision to the new revision.  This\n-\t# is to show the truth of what happened in this change.  There's no point\n-\t# showing the stat from the base to the new revision because the base\n-\t# is effectively a random revision at this point - the user will be\n-\t# interested in what this revision changed - including the undoing of\n-\t# previous revisions in the case of non-fast forward updates.\n+\t# The diffstat is shown from the old revision to the new revision.\n+\t# This is to show the truth of what happened in this change.\n+\t# There's no point showing the stat from the base to the new\n+\t# revision because the base is effectively a random revision at this\n+\t# point - the user will be interested in what this revision changed\n+\t# - including the undoing of previous revisions in the case of\n+\t# non-fast forward updates.\n \techo \"\"\n \techo \"Summary of changes:\"\n \tgit diff-tree --stat --summary --find-copies-harder $oldrev..$newrev\n@@ -448,7 +456,8 @@ generate_update_atag_email()\n #\n generate_atag_email()\n {\n-\t# Use git-for-each-ref to pull out the individual fields from the tag\n+\t# Use git-for-each-ref to pull out the individual fields from the\n+\t# tag\n \teval $(git for-each-ref --shell --format='\n \ttagobject=%(*objectname)\n \ttagtype=%(*objecttype)\n@@ -459,8 +468,10 @@ generate_atag_email()\n \techo \"   tagging  $tagobject ($tagtype)\"\n \tcase \"$tagtype\" in\n \tcommit)\n+\n \t\t# If the tagged object is a commit, then we assume this is a\n-\t\t# release, and so we calculate which tag this tag is replacing\n+\t\t# release, and so we calculate which tag this tag is\n+\t\t# replacing\n \t\tprevtag=$(git describe --abbrev=0 $newrev^ 2>/dev/null)\n \n \t\tif [ -n \"$prevtag\" ]; then\n@@ -477,25 +488,27 @@ generate_atag_email()\n \techo \"\"\n \techo $LOGBEGIN\n \n-\t# Show the content of the tag message; this might contain a change log\n-\t# or release notes so is worth displaying.\n+\t# Show the content of the tag message; this might contain a change\n+\t# log or release notes so is worth displaying.\n \tgit cat-file tag $newrev | sed -e '1,/^$/d'\n \n \techo \"\"\n \tcase \"$tagtype\" in\n \tcommit)\n-\t\t# Only commit tags make sense to have rev-list operations performed\n-\t\t# on them\n+\t\t# Only commit tags make sense to have rev-list operations\n+\t\t# performed on them\n \t\tif [ -n \"$prevtag\" ]; then\n \t\t\t# Show changes since the previous release\n \t\t\tgit rev-list --pretty=short \"$prevtag..$newrev\" | git shortlog\n \t\telse\n-\t\t\t# No previous tag, show all the changes since time began\n+\t\t\t# No previous tag, show all the changes since time\n+\t\t\t# began\n \t\t\tgit rev-list --pretty=short $newrev | git shortlog\n \t\tfi\n \t\t;;\n \t*)\n-\t\t# XXX: Is there anything useful we can do for non-commit objects?\n+\t\t# XXX: Is there anything useful we can do for non-commit\n+\t\t# objects?\n \t\t;;\n \tesac\n \n@@ -544,13 +557,14 @@ generate_update_general_email()\n #\n generate_general_email()\n {\n-\t# Unannotated tags are more about marking a point than releasing a version;\n-\t# therefore we don't do the shortlog summary that we do for annotated tags\n-\t# above - we simply show that the point has been marked, and print the log\n-\t# message for the marked point for reference purposes\n+\t# Unannotated tags are more about marking a point than releasing a\n+\t# version; therefore we don't do the shortlog summary that we do for\n+\t# annotated tags above - we simply show that the point has been\n+\t# marked, and print the log message for the marked point for\n+\t# reference purposes\n \t#\n-\t# Note this section also catches any other reference type (although there\n-\t# aren't any) and deals with them in the same way.\n+\t# Note this section also catches any other reference type (although\n+\t# there aren't any) and deals with them in the same way.\n \n \techo \"\"\n \tif [ \"$newrev_type\" = \"commit\" ]; then\n@@ -558,10 +572,10 @@ generate_general_email()\n \t\tgit show --no-color --root -s $newrev\n \t\techo $LOGEND\n \telse\n-\t\t# What can we do here?  The tag marks an object that is not a commit,\n-\t\t# so there is no log for us to display.  It's probably not wise to\n-\t\t# output git-cat-file as it could be a binary blob.  We'll just say how\n-\t\t# big it is\n+\t\t# What can we do here?  The tag marks an object that is not\n+\t\t# a commit, so there is no log for us to display.  It's\n+\t\t# probably not wise to output git-cat-file as it could be a\n+\t\t# binary blob.  We'll just say how big it is\n \t\techo \"$newrev is a $newrev_type, and is $(git cat-file -s $newrev) bytes long.\"\n \tfi\n }\n@@ -604,8 +618,8 @@ if [ -z \"$GIT_DIR\" ]; then\n fi\n \n projectdesc=$(sed -ne '1p' \"$GIT_DIR/description\")\n-# Check if the description is unchanged from it's default, and shorten it to a\n-# more manageable length if it is\n+# Check if the description is unchanged from it's default, and shorten it to\n+# a more manageable length if it is\n if expr \"$projectdesc\" : \"Unnamed repository.*$\" >/dev/null\n then\n \tprojectdesc=\"UNNAMED PROJECT\"\n@@ -616,11 +630,12 @@ announcerecipients=$(git repo-config hooks.announcelist)\n envelopesender=$(git-repo-config hooks.envelopesender)\n \n # --- Main loop\n-# Allow dual mode: run from the command line just like the update hook, or if\n-# no arguments are given then run as a hook script\n+# Allow dual mode: run from the command line just like the update hook, or\n+# if no arguments are given then run as a hook script\n if [ -n \"$1\" -a -n \"$2\" -a -n \"$3\" ]; then\n \t# Output to the terminal in command line mode - if someone wanted to\n-\t# resend an email; they could redirect the output to sendmail themselves\n+\t# resend an email; they could redirect the output to sendmail\n+\t# themselves\n \tPAGER= generate_email $2 $3 $1\n else\n \twhile read oldrev newrev refname\n-- \n1.5.3.5\n"}]}