Just before updating the ref on the remote repository, the update hook
is invoked.  Its exit status determines the success or failure of
the ref update.

The hook executes once for each ref to be updated, and takes
three parameters:

 - the name of the ref being updated,
 - the old object name stored in the ref,
 - and the new object name to be stored in the ref.

A zero exit from the update hook allows the ref to be updated.
Exiting with a non-zero status prevents `git receive-pack`
from updating that ref.

This hook can be used to prevent 'forced' update on certain refs by
making sure that the object name is a commit object that is a
descendant of the commit object named by the old object name.
That is, to enforce a "fast-forward only" policy.

It could also be used to log the old..new status.  However, it
does not know the entire set of branches, so it would end up
firing one e-mail per ref when used naively, though.  The
<<post-receive,'post-receive'>> hook is more suited to that.

In an environment that restricts the users' access only to git
commands over the wire, this hook can be used to implement access
control without relying on filesystem ownership and group
membership. See linkgit:git-shell[1] for how you might use the login
shell to restrict the user's access to only git commands.

Both standard output and standard error output are forwarded to
`git send-pack` on the other end, so you can simply `echo` messages
for the user.

The default 'update' hook, when enabled--and with
`hooks.allowunannotated` config option unset or set to false--prevents
unannotated tags from being pushed.

[[proc-receive]]
proc-receive
~~~~~~~~~~~~

This hook is invoked by linkgit:git-receive-pack[1].  If the server has
set the multi-valued config variable `receive.procReceiveRefs`, and the
commands sent to 'receive-pack' have matching reference names, these
commands will be executed by this hook, instead of by the internal
`execute_commands()` function.  This hook is responsible for updating
the relevant references and reporting the results back to 'receive-pack'.

This hook executes once for the receive operation.  It takes no
arguments, but uses a pkt-line format protocol to communicate with
'receive-pack' to read commands, push-options and send results.  In the
following example for the protocol, the letter 'S' stands for
'receive-pack' and the letter 'H' stands for this hook.

    # Version and features negotiation.
    S: PKT-LINE(version=1\0push-options atomic...)
    S: flush-pkt
    H: PKT-LINE(version=1\0push-options...)
    H: flush-pkt

    # Send commands from server to the hook.
    S: PKT-LINE(<old-oid> <new-oid> <ref>)
    S: ... ...
    S: flush-pkt
    # Send push-options only if the 'push-options' feature is enabled.
    S: PKT-LINE(push-option)
    S: ... ...
    S: flush-pkt

    # Receive results from the hook.
    # OK, run this command successfully.
    H: PKT-LINE(ok <ref>)
    # NO, I reject it.
    H: PKT-LINE(ng <ref> <reason>)
    # Fall through, let 'receive-pack' execute it.
    H: PKT-LINE(ok <ref>)
    H: PKT-LINE(option fall-through)
    # OK, but has an alternate reference.  The alternate reference name
    # and other status can be given in option directives.
    H: PKT-LINE(ok <ref>)
    H: PKT-LINE(option refname <refname>)
    H: PKT-LINE(option old-oid <old-oid>)
    H: PKT-LINE(option new-oid <new-oid>)
    H: PKT-LINE(option forced-update)
    H: ... ...
    H: flush-pkt

Each command for the 'proc-receive' hook may point to a pseudo-reference
and always has a zero-old as its old-oid, while the 'proc-receive' hook
may update an alternate reference and the alternate reference may exist
already with a non-zero old-oid.  For this case, this hook will use
"option" directives to report extended attributes for the reference given
by the leading "ok" directive.

The report of the commands of this hook should have the same order as
the input.  The exit status of the 'proc-receive' hook only determines
the