]>
Commit | Line | Data |
---|---|---|
2a245013 JH |
1 | git-receive-pack(1) |
2 | =================== | |
2a245013 JH |
3 | |
4 | NAME | |
5 | ---- | |
c3f0baac | 6 | git-receive-pack - Receive what is pushed into the repository |
2a245013 JH |
7 | |
8 | ||
9 | SYNOPSIS | |
10 | -------- | |
0b444cdb | 11 | 'git-receive-pack' <directory> |
2a245013 JH |
12 | |
13 | DESCRIPTION | |
14 | ----------- | |
0b444cdb | 15 | Invoked by 'git send-pack' and updates the repository with the |
2a245013 JH |
16 | information fed from the remote end. |
17 | ||
18 | This command is usually not invoked directly by the end user. | |
0b444cdb | 19 | The UI for the protocol is on the 'git send-pack' side, and the |
2a245013 | 20 | program pair is meant to be used to push updates to remote |
483bc4f0 | 21 | repository. For pull operations, see linkgit:git-fetch-pack[1]. |
2a245013 | 22 | |
a75d7b54 | 23 | The command allows for creation and fast-forwarding of sha1 refs |
b1bf95bb | 24 | (heads/tags) on the remote end (strictly speaking, it is the |
ba020ef5 | 25 | local end 'git-receive-pack' runs, but to the user who is sitting at |
b1bf95bb JW |
26 | the send-pack end, it is updating the remote. Confused?) |
27 | ||
05ef58ec SP |
28 | There are other real-world examples of using update and |
29 | post-update hooks found in the Documentation/howto directory. | |
b1bf95bb | 30 | |
ba020ef5 | 31 | 'git-receive-pack' honours the receive.denyNonFastForwards config |
05ef58ec SP |
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 | |
f43cd49f SP |
43 | and is executable, it will be invoked once with no parameters. The |
44 | standard input of the hook will be one line per ref to be updated: | |
05ef58ec | 45 | |
f43cd49f | 46 | sha1-old SP sha1-new SP refname LF |
05ef58ec | 47 | |
f43cd49f SP |
48 | The refname value is relative to $GIT_DIR; e.g. for the master |
49 | head this is "refs/heads/master". The two sha1 values before | |
05ef58ec | 50 | each refname are the object names for the refname before and after |
967506bb JK |
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 | |
05ef58ec SP |
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. | |
b1bf95bb | 62 | |
05ef58ec SP |
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: | |
b1bf95bb | 67 | |
05ef58ec | 68 | $GIT_DIR/hooks/update refname sha1-old sha1-new |
b1bf95bb | 69 | |
05ef58ec SP |
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, | |
967506bb | 74 | so either sha1-old is 0\{40} (meaning there is no such ref yet), |
05ef58ec SP |
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 | |
02783075 | 81 | ensure the ref will actually be updated, it is only a prerequisite. |
05ef58ec SP |
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 | |
04c8ce9c | 89 | file exists and is executable, it will be invoked once with no |
f43cd49f SP |
90 | parameters. The standard input of the hook will be one line |
91 | for each successfully updated ref: | |
05ef58ec | 92 | |
f43cd49f | 93 | sha1-old SP sha1-new SP refname LF |
05ef58ec | 94 | |
f43cd49f SP |
95 | The refname value is relative to $GIT_DIR; e.g. for the master |
96 | head this is "refs/heads/master". The two sha1 values before | |
05ef58ec SP |
97 | each refname are the object names for the refname before and after |
98 | the update. Refs that were created will have sha1-old equal to | |
967506bb JK |
99 | 0\{40}, while refs that were deleted will have sha1-new equal to |
100 | 0\{40}, otherwise sha1-old and sha1-new should be valid objects in | |
05ef58ec SP |
101 | the repository. |
102 | ||
103 | Using this hook, it is easy to generate mails describing the updates | |
104 | to the repository. This example script sends one mail message per | |
105 | ref listing the commits pushed to the repository: | |
b1bf95bb JW |
106 | |
107 | #!/bin/sh | |
19614330 | 108 | # mail out commit update information. |
f43cd49f | 109 | while read oval nval ref |
05ef58ec | 110 | do |
f43cd49f | 111 | if expr "$oval" : '0*$' >/dev/null |
05ef58ec SP |
112 | then |
113 | echo "Created a new ref, with the following commits:" | |
b1889c36 | 114 | git rev-list --pretty "$nval" |
05ef58ec SP |
115 | else |
116 | echo "New commits:" | |
b1889c36 | 117 | git rev-list --pretty "$nval" "^$oval" |
05ef58ec | 118 | fi | |
f43cd49f | 119 | mail -s "Changes to ref $ref" commit-list@mydomain |
05ef58ec | 120 | done |
b1bf95bb | 121 | exit 0 |
2a245013 | 122 | |
05ef58ec SP |
123 | The exit code from this hook invocation is ignored, however a |
124 | non-zero exit code will generate an error message. | |
19614330 | 125 | |
05ef58ec SP |
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 | |
ba020ef5 | 128 | after it was updated by 'git-receive-pack', but before the hook was able |
05ef58ec SP |
129 | to evaluate it. It is recommended that hooks rely on sha1-new |
130 | rather than the current value of refname. | |
19614330 | 131 | |
05ef58ec SP |
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 | |
04c8ce9c | 136 | post-update will be called with the list of refs that have been updated. |
05ef58ec | 137 | This can be used to implement any repository wide cleanup tasks. |
eb0362a4 | 138 | |
05ef58ec | 139 | The exit code from this hook invocation is ignored; the only thing |
ba020ef5 | 140 | left for 'git-receive-pack' to do at that point is to exit itself |
05ef58ec | 141 | anyway. |
eb0362a4 | 142 | |
483bc4f0 | 143 | This hook can be used, for example, to run `git update-server-info` |
05ef58ec SP |
144 | if the repository is packed and is served via a dumb transport. |
145 | ||
146 | #!/bin/sh | |
b1889c36 | 147 | exec git update-server-info |
2a245013 | 148 | |
6d35cc76 JH |
149 | |
150 | SEE ALSO | |
151 | -------- | |
5162e697 | 152 | linkgit:git-send-pack[1] |
6d35cc76 JH |
153 | |
154 | ||
2a245013 JH |
155 | Author |
156 | ------ | |
157 | Written by Linus Torvalds <torvalds@osdl.org> | |
158 | ||
159 | Documentation | |
160 | -------------- | |
161 | Documentation by Junio C Hamano. | |
162 | ||
163 | GIT | |
164 | --- | |
9e1f0a85 | 165 | Part of the linkgit:git[1] suite |