inspected, just as
in `pre-receive` hook, after accepting a signed push.

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, and logs the push
certificates of signed pushes with good signatures to a logger
service:

----
#!/bin/sh
# mail out commit update information.
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Created a new ref, with the following commits:"
		git rev-list --pretty "$nval"
	else
		echo "New commits:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "Changes to ref $ref" commit-list@mydomain
done
# log signed push certificate, if any
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
	(
		echo expected nonce is ${GIT_PUSH_NONCE}
		git cat-file blob ${GIT_PUSH_CERT}
	) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0
----

The exit code from this hook invocation is ignored, however a
non-zero exit code will generate an error message.

Note that it is possible for refname to not have sha1-new when this
hook runs.  This can easily occur if another user modifies the ref
after it was updated by 'git-receive-pack', but before the hook was able
to evaluate it.  It is recommended that hooks rely on sha1-new
rather than the current value of refname.

POST-UPDATE HOOK
----------------
After all other processing, if at least one ref was updated, and
if $GIT_DIR/hooks/post-update file exists and is executable, then
post-update will be called with the list of refs that have been updated.
This can be used to implement any repository wide cleanup tasks.

The exit code from this hook invocation is ignored; the only thing
left for 'git-receive-pack' to do at that point is to exit itself
anyway.

This hook can be used, for example, to run `git update-server-info`
if the repository is packed and is served via a dumb transport.

----
#!/bin/sh
exec git update-server-info
----


QUARANTINE ENVIRONMENT
----------------------

When `receive-pack` takes in objects, they are placed into a temporary
"quarantine" directory within the `$GIT_DIR/objects` directory and
migrated into the main object store only after the `pre-receive` hook
has completed. If the push fails before then, the temporary directory is
removed entirely.

This has a few user-visible effects and caveats:

  1. Pushes which fail due to problems with the incoming pack, missing
     objects, or due to the `pre-receive` hook will not leave any
     on-disk data. This is usually helpful to prevent repeated failed
     pushes from filling up your disk, but can make debugging more
     challenging.

  2. Any objects created by the `pre-receive` hook will be created in
     the quarantine directory (and migrated only if it succeeds).

  3. The `pre-receive` hook MUST NOT update any refs to point to
     quarantined objects. Other programs accessing the repository will
     not be able to see the objects (and if the pre-receive hook fails,
     those refs would become corrupted). For safety, any ref updates
     from within `pre-receive` are automatically rejected.


SEE ALSO
--------
linkgit:git-send-pack[1], linkgit:gitnamespaces[7]

GIT
---
Part of the linkgit:git[1] suite