@@ -25,61 +25,126 @@ The command allows for creation and fast forwarding of sha1 refs
2525local end receive-pack runs, but to the user who is sitting at
2626the send-pack end, it is updating the remote. Confused?)
2727
28- Before each ref is updated, if $GIT_DIR/hooks/ update file exists
29- and executable, it is called with three parameters:
28+ There are other real-world examples of using update and
29+ post-update hooks found in the Documentation/howto directory.
3030
31- $GIT_DIR/hooks/update refname sha1-old sha1-new
31+ git-receive-pack honours the receive.denyNonFastForwards config
32+ option, which tells it if updates to a ref should be denied if they
33+ are not fast-forwards.
34+
35+ OPTIONS
36+ -------
37+ <directory>::
38+ The repository to sync into.
39+
40+ pre-receive Hook
41+ ----------------
42+ Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists
43+ and is executable, it will be invoked once, with three parameters
44+ per ref to be updated:
45+
46+ $GIT_DIR/hooks/pre-receive (refname sha1-old sha1-new)+
47+
48+ The refname parameter is relative to $GIT_DIR; e.g. for the master
49+ head this is "refs/heads/master". The two sha1 arguments after
50+ each refname are the object names for the refname before and after
51+ the update. Refs to be created will have sha1-old equal to 0{40},
52+ while refs to be deleted will have sha1-new equal to 0{40}, otherwise
53+ sha1-old and sha1-new should be valid objects in the repository.
54+
55+ This hook is called before any refname is updated and before any
56+ fast-forward checks are performed.
57+
58+ If the pre-receive hook exits with a non-zero exit status no updates
59+ will be performed, and the update, post-receive and post-update
60+ hooks will not be invoked either. This can be useful to quickly
61+ bail out if the update is not to be supported.
3262
33- The refname parameter is relative to $GIT_DIR; e.g. for the
34- master head this is "refs/heads/master". Two sha1 are the
35- object names for the refname before and after the update. Note
36- that the hook is called before the refname is updated, so either
37- sha1-old is 0{40} (meaning there is no such ref yet), or it
38- should match what is recorded in refname.
63+ update Hook
64+ -----------
65+ Before each ref is updated, if $GIT_DIR/hooks/update file exists
66+ and is executable, it is invoked once per ref, with three parameters:
3967
40- The hook should exit with non-zero status if it wants to
41- disallow updating the named ref. Otherwise it should exit with
42- zero.
68+ $GIT_DIR/hooks/update refname sha1-old sha1-new
4369
44- Using this hook, it is easy to generate mails on updates to
45- the local repository. This example script sends a mail with
46- the commits pushed to the repository:
70+ The refname parameter is relative to $GIT_DIR; e.g. for the master
71+ head this is "refs/heads/master". The two sha1 arguments are
72+ the object names for the refname before and after the update.
73+ Note that the hook is called before the refname is updated,
74+ so either sha1-old is 0{40} (meaning there is no such ref yet),
75+ or it should match what is recorded in refname.
76+
77+ The hook should exit with non-zero status if it wants to disallow
78+ updating the named ref. Otherwise it should exit with zero.
79+
80+ Successful execution (a zero exit status) of this hook does not
81+ ensure the ref will actully be updated, it is only a prerequisite.
82+ As such it is not a good idea to send notices (e.g. email) from
83+ this hook. Consider using the post-receive hook instead.
84+
85+ post-receive Hook
86+ -----------------
87+ After all refs were updated (or attempted to be updated), if any
88+ ref update was successful, and if $GIT_DIR/hooks/post-receive
89+ file exists and is executable, it will be invoke once with three
90+ parameters for each successfully updated ref:
91+
92+ $GIT_DIR/hooks/post-receive (refname sha1-old sha1-new)+
93+
94+ The refname parameter is relative to $GIT_DIR; e.g. for the master
95+ head this is "refs/heads/master". The two sha1 arguments after
96+ each refname are the object names for the refname before and after
97+ the update. Refs that were created will have sha1-old equal to
98+ 0{40}, while refs that were deleted will have sha1-new equal to
99+ 0{40}, otherwise sha1-old and sha1-new should be valid objects in
100+ the repository.
101+
102+ Using this hook, it is easy to generate mails describing the updates
103+ to the repository. This example script sends one mail message per
104+ ref listing the commits pushed to the repository:
47105
48106 #!/bin/sh
49107 # mail out commit update information.
50- if expr "$2" : '0*$' >/dev/null
51- then
52- echo "Created a new ref, with the following commits:"
53- git-rev-list --pretty "$2"
54- else
55- echo "New commits:"
56- git-rev-list --pretty "$3" "^$2"
57- fi |
58- mail -s "Changes to ref $1" commit-list@mydomain
108+ while test $# -gt 0
109+ do
110+ if expr "$2" : '0*$' >/dev/null
111+ then
112+ echo "Created a new ref, with the following commits:"
113+ git-rev-list --pretty "$2"
114+ else
115+ echo "New commits:"
116+ git-rev-list --pretty "$3" "^$2"
117+ fi |
118+ mail -s "Changes to ref $1" commit-list@mydomain
119+ shift; shift; shift; # discard this ref's args
120+ done
59121 exit 0
60122
61- Another hook $GIT_DIR/hooks/post-update, if exists and
62- executable, is called with the list of refs that have been
63- updated. This can be used to implement repository wide cleanup
64- task if needed. The exit code from this hook invocation is
65- ignored; the only thing left for git-receive-pack to do at that
66- point is to exit itself anyway. This hook can be used, for
67- example, to run "git-update-server-info" if the repository is
68- packed and is served via a dumb transport.
123+ The exit code from this hook invocation is ignored, however a
124+ non-zero exit code will generate an error message.
69125
70- #!/bin/sh
71- exec git-update-server-info
126+ Note that it is possible for refname to not have sha1-new when this
127+ hook runs. This can easily occur if another user modifies the ref
128+ after it was updated by receive-pack, but before the hook was able
129+ to evaluate it. It is recommended that hooks rely on sha1-new
130+ rather than the current value of refname.
72131
73- There are other real-world examples of using update and
74- post-update hooks found in the Documentation/howto directory.
132+ post-update Hook
133+ ----------------
134+ After all other processing, if at least one ref was updated, and
135+ if $GIT_DIR/hooks/post-update file exists and is executable, then
136+ post-update will called with the list of refs that have been updated.
137+ This can be used to implement any repository wide cleanup tasks.
75138
76- git-receive-pack honours the receive.denyNonFastforwards flag, which
77- tells it if updates to a ref should be denied if they are not fast-forwards.
139+ The exit code from this hook invocation is ignored; the only thing
140+ left for git-receive-pack to do at that point is to exit itself
141+ anyway.
78142
79- OPTIONS
80- -------
81- <directory>::
82- The repository to sync into.
143+ This hook can be used, for example, to run "git-update-server-info"
144+ if the repository is packed and is served via a dumb transport.
145+
146+ #!/bin/sh
147+ exec git-update-server-info
83148
84149
85150SEE ALSO
0 commit comments