# 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 success or failure of the group of commands sent to it, unless
atomic push is in use.
[[post-receive]]
post-receive
~~~~~~~~~~~~
This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
`git push` and updates reference(s) in its repository.
The hook executes on the remote repository once after all the proposed
ref updates are processed and if at least one ref is updated as the
result.
The hook takes no arguments. It receives one line on standard input for
each ref that is successfully updated following the same format as the
<<pre-receive,'pre-receive'>> hook.
This hook does not affect the outcome of `git receive-pack`, as it
is called after the real work is done.
This supersedes the <<post-update,'post-update'>> hook in that it gets
both old and new values of all the refs in addition to their
names.
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 'post-receive' hook is empty, but there is
a sample script `post-receive-email` provided in the `contrib/hooks`
directory in Git distribution, which implements sending commit
emails.
The number of push options given on the command line of
`git push --push-option=...` can be read from the environment
variable `GIT_PUSH_OPTION_COUNT`, and the options themselves are
found in `GIT_PUSH_OPTION_0`, `GIT_PUSH_OPTION_1`,...
If it is negotiated to not use the push options phase, the
environment variables will not be set. If the client selects
to use push options, but doesn't transmit any, the count variable
will be set to zero, `GIT_PUSH_OPTION_COUNT=0`.
See the "post-receive" section in linkgit:git-receive-pack[1] for
additional details.
[[post-update]]
post-update
~~~~~~~~~~~
This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
`git push` and updates reference(s) in its repository.
It executes on the remote repository once after all the refs have
been updated.
It takes a variable number of parameters, each of which is the
name of ref that was actually updated.
This hook is meant primarily for notification, and cannot affect
the outcome of `git receive-pack`.
The 'post-update' hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
so it is a poor place to do log old..new. The
<<post-receive,'post-receive'>> hook does get both original and
updated values of the refs. You might consider it instead if you need
them.
When enabled, the default 'post-update' hook runs
`git update-server-info` to keep the information used by dumb
transports (e.g., HTTP) up to date. If you are publishing
a Git repository that is accessible via HTTP, you should
probably enable this hook.
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.
reference-transaction
~~~~~~~~~~~~~~~~~~~~~
This hook is invoked by any Git command that performs