+The refname parameter is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 arguments are
+the object names for the refname before and after the update.
+Note that the hook is called before the refname is updated,
+so either sha1-old is 0{40} (meaning there is no such ref yet),
+or it should match what is recorded in refname.
+
+The hook should exit with non-zero status if it wants to disallow
+updating the named ref. Otherwise it should exit with zero.
+
+Successful execution (a zero exit status) of this hook does not
+ensure the ref will actully be updated, it is only a prerequisite.
+As such it is not a good idea to send notices (e.g. email) from
+this hook. Consider using the post-receive hook instead.
+
+post-receive Hook
+-----------------
+After all refs were updated (or attempted to be updated), if any
+ref update was successful, and if $GIT_DIR/hooks/post-receive
+file exists and is executable, it will be invoke once with three
+parameters for each successfully updated ref:
+
+ $GIT_DIR/hooks/post-receive (refname sha1-old sha1-new)+
+
+The refname parameter is relative to $GIT_DIR; e.g. for the master
+head this is "refs/heads/master". The two sha1 arguments after
+each refname are the object names for the refname before and after
+the update. Refs that were created will have sha1-old equal to
+0{40}, while refs that were deleted will have sha1-new equal to
+0{40}, otherwise sha1-old and sha1-new should be valid objects in
+the repository.
+
+Using this hook, it is easy to generate mails describing the updates
+to the repository. This example script sends one mail message per
+ref listing the commits pushed to the repository: