hook is called with two parameters
which provide the name and location of the destination remote, if a
named remote is not being used both values will be the same.
Information about what is to be pushed is provided on the hook's standard
input with lines of the form:
<local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF
For instance, if the command +git push origin master:foreign+ were run the
hook would receive a line like the following:
refs/heads/master 67890 refs/heads/foreign 12345
although the full object name would be supplied. If the foreign ref does not
yet exist the `<remote-object-name>` will be the all-zeroes object name. If a
ref is to be deleted, the `<local-ref>` will be supplied as `(delete)` and the
`<local-object-name>` will be the all-zeroes object name. If the local commit
was specified by something other than a name which could be expanded (such as
`HEAD~`, or an object name) it will be supplied as it was originally given.
If this hook exits with a non-zero status, `git push` will abort without
pushing anything. Information about why the push is rejected may be sent
to the user by writing to standard error.
[[pre-receive]]
pre-receive
~~~~~~~~~~~
This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
`git push` and updates reference(s) in its repository.
Just before starting to update refs on the remote repository, the
pre-receive hook is invoked. Its exit status determines the success
or failure of the update.
This hook executes once for the receive operation. It takes no
arguments, but for each ref to be updated it receives on standard
input a line of the format:
<old-oid> SP <new-oid> SP <ref-name> LF
where `<old-oid>` is the old object name stored in the ref,
`<new-oid>` is the new object name to be stored in the ref and
`<ref-name>` is the full name of the ref.
When creating a new ref, `<old-oid>` is the all-zeroes object name.
If the hook exits with non-zero status, none of the refs will be
updated. If the hook exits with zero, updating of individual refs can
still be prevented by the <<update,'update'>> 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.
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 section on "Quarantine Environment" in
linkgit:git-receive-pack[1] for some caveats.
[[update]]
update
~~~~~~
This hook is invoked by linkgit:git-receive-pack[1] when it reacts to
`git push` and updates reference(s) in its repository.
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.