name.  See the
description of `post-receive` hook for an example.  In addition, the
certificate is verified using GPG and the result is exported with
the following environment variables:

`GIT_PUSH_CERT_SIGNER`::
	The name and the e-mail address of the owner of the key that
	signed the push certificate.

`GIT_PUSH_CERT_KEY`::
	The GPG key ID of the key that signed the push certificate.

`GIT_PUSH_CERT_STATUS`::
	The status of GPG verification of the push certificate,
	using the same mnemonic as used in `%G?` format of `git log`
	family of commands (see linkgit:git-log[1]).

`GIT_PUSH_CERT_NONCE`::
	The nonce string the process asked the signer to include
	in the push certificate.  If this does not match the value
	recorded on the "nonce" header in the push certificate, it
	may indicate that the certificate is a valid one that is
	being replayed from a separate "git push" session.

`GIT_PUSH_CERT_NONCE_STATUS`::
`UNSOLICITED`;;
	"git push --signed" sent a nonce when we did not ask it to
	send one.
`MISSING`;;
	"git push --signed" did not send any nonce header.
`BAD`;;
	"git push --signed" sent a bogus nonce.
`OK`;;
	"git push --signed" sent the nonce we asked it to send.
`SLOP`;;
	"git push --signed" sent a nonce different from what we
	asked it to send now, but in a previous session.  See
	`GIT_PUSH_CERT_NONCE_SLOP` environment variable.

`GIT_PUSH_CERT_NONCE_SLOP`::
	"git push --signed" sent a nonce different from what we
	asked it to send now, but in a different session whose
	starting time is different by this many seconds from the
	current session.  Only meaningful when
	`GIT_PUSH_CERT_NONCE_STATUS` says `SLOP`.
	Also read about `receive.certNonceSlop` variable in
	linkgit:git-config[1].

This hook is called before any refname is updated and before any
fast-forward checks are performed.

If the pre-receive hook exits with a non-zero exit status no updates
will be performed, and the update, post-receive and post-update
hooks will not be invoked either.  This can be useful to quickly
bail out if the update is not to be supported.

See the notes on the quarantine environment below.

UPDATE HOOK
-----------
Before each ref is updated, if $GIT_DIR/hooks/update file exists
and is executable, it is invoked once per ref, with three parameters:

       $GIT_DIR/hooks/update 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 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 actually 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 invoked once with no
parameters.  The standard input of the hook will be one line
for each successfully updated ref:

       sha1-old SP sha1-new SP refname LF

The refname value is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master".  The two sha1 values before
each refname are the object names