worktree: invoke post-checkout hook (unless --no-checkout)
[git/git.git] / Documentation / githooks.txt
1 githooks(5)
2 ===========
3
4 NAME
5 ----
6 githooks - Hooks used by Git
7
8 SYNOPSIS
9 --------
10 $GIT_DIR/hooks/* (or \`git config core.hooksPath`/*)
11
12
13 DESCRIPTION
14 -----------
15
16 Hooks are programs you can place in a hooks directory to trigger
17 actions at certain points in git's execution. Hooks that don't have
18 the executable bit set are ignored.
19
20 By default the hooks directory is `$GIT_DIR/hooks`, but that can be
21 changed via the `core.hooksPath` configuration variable (see
22 linkgit:git-config[1]).
23
24 Before Git invokes a hook, it changes its working directory to either
25 $GIT_DIR in a bare repository or the root of the working tree in a non-bare
26 repository. An exception are hooks triggered during a push ('pre-receive',
27 'update', 'post-receive', 'post-update', 'push-to-checkout') which are always
28 executed in $GIT_DIR.
29
30 Hooks can get their arguments via the environment, command-line
31 arguments, and stdin. See the documentation for each hook below for
32 details.
33
34 'git init' may copy hooks to the new repository, depending on its
35 configuration. See the "TEMPLATE DIRECTORY" section in
36 linkgit:git-init[1] for details. When the rest of this document refers
37 to "default hooks" it's talking about the default template shipped
38 with Git.
39
40 The currently supported hooks are described below.
41
42 HOOKS
43 -----
44
45 applypatch-msg
46 ~~~~~~~~~~~~~~
47
48 This hook is invoked by 'git am'. It takes a single
49 parameter, the name of the file that holds the proposed commit
50 log message. Exiting with a non-zero status causes 'git am' to abort
51 before applying the patch.
52
53 The hook is allowed to edit the message file in place, and can
54 be used to normalize the message into some project standard
55 format. It can also be used to refuse the commit after inspecting
56 the message file.
57
58 The default 'applypatch-msg' hook, when enabled, runs the
59 'commit-msg' hook, if the latter is enabled.
60
61 pre-applypatch
62 ~~~~~~~~~~~~~~
63
64 This hook is invoked by 'git am'. It takes no parameter, and is
65 invoked after the patch is applied, but before a commit is made.
66
67 If it exits with non-zero status, then the working tree will not be
68 committed after applying the patch.
69
70 It can be used to inspect the current working tree and refuse to
71 make a commit if it does not pass certain test.
72
73 The default 'pre-applypatch' hook, when enabled, runs the
74 'pre-commit' hook, if the latter is enabled.
75
76 post-applypatch
77 ~~~~~~~~~~~~~~~
78
79 This hook is invoked by 'git am'. It takes no parameter,
80 and is invoked after the patch is applied and a commit is made.
81
82 This hook is meant primarily for notification, and cannot affect
83 the outcome of 'git am'.
84
85 pre-commit
86 ~~~~~~~~~~
87
88 This hook is invoked by 'git commit', and can be bypassed
89 with the `--no-verify` option. It takes no parameters, and is
90 invoked before obtaining the proposed commit log message and
91 making a commit. Exiting with a non-zero status from this script
92 causes the 'git commit' command to abort before creating a commit.
93
94 The default 'pre-commit' hook, when enabled, catches introduction
95 of lines with trailing whitespaces and aborts the commit when
96 such a line is found.
97
98 All the 'git commit' hooks are invoked with the environment
99 variable `GIT_EDITOR=:` if the command will not bring up an editor
100 to modify the commit message.
101
102 prepare-commit-msg
103 ~~~~~~~~~~~~~~~~~~
104
105 This hook is invoked by 'git commit' right after preparing the
106 default log message, and before the editor is started.
107
108 It takes one to three parameters. The first is the name of the file
109 that contains the commit log message. The second is the source of the commit
110 message, and can be: `message` (if a `-m` or `-F` option was
111 given); `template` (if a `-t` option was given or the
112 configuration option `commit.template` is set); `merge` (if the
113 commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
114 (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
115 a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given).
116
117 If the exit status is non-zero, 'git commit' will abort.
118
119 The purpose of the hook is to edit the message file in place, and
120 it is not suppressed by the `--no-verify` option. A non-zero exit
121 means a failure of the hook and aborts the commit. It should not
122 be used as replacement for pre-commit hook.
123
124 The sample `prepare-commit-msg` hook that comes with Git removes the
125 help message found in the commented portion of the commit template.
126
127 commit-msg
128 ~~~~~~~~~~
129
130 This hook is invoked by 'git commit' and 'git merge', and can be
131 bypassed with the `--no-verify` option. It takes a single parameter,
132 the name of the file that holds the proposed commit log message.
133 Exiting with a non-zero status causes the command to abort.
134
135 The hook is allowed to edit the message file in place, and can be used
136 to normalize the message into some project standard format. It
137 can also be used to refuse the commit after inspecting the message
138 file.
139
140 The default 'commit-msg' hook, when enabled, detects duplicate
141 "Signed-off-by" lines, and aborts the commit if one is found.
142
143 post-commit
144 ~~~~~~~~~~~
145
146 This hook is invoked by 'git commit'. It takes no parameters, and is
147 invoked after a commit is made.
148
149 This hook is meant primarily for notification, and cannot affect
150 the outcome of 'git commit'.
151
152 pre-rebase
153 ~~~~~~~~~~
154
155 This hook is called by 'git rebase' and can be used to prevent a
156 branch from getting rebased. The hook may be called with one or
157 two parameters. The first parameter is the upstream from which
158 the series was forked. The second parameter is the branch being
159 rebased, and is not set when rebasing the current branch.
160
161 post-checkout
162 ~~~~~~~~~~~~~
163
164 This hook is invoked when a 'git checkout' is run after having updated the
165 worktree. The hook is given three parameters: the ref of the previous HEAD,
166 the ref of the new HEAD (which may or may not have changed), and a flag
167 indicating whether the checkout was a branch checkout (changing branches,
168 flag=1) or a file checkout (retrieving a file from the index, flag=0).
169 This hook cannot affect the outcome of 'git checkout'.
170
171 It is also run after 'git clone', unless the --no-checkout (-n) option is
172 used. The first parameter given to the hook is the null-ref, the second the
173 ref of the new HEAD and the flag is always 1. Likewise for 'git worktree add'
174 unless --no-checkout is used.
175
176 This hook can be used to perform repository validity checks, auto-display
177 differences from the previous HEAD if different, or set working dir metadata
178 properties.
179
180 post-merge
181 ~~~~~~~~~~
182
183 This hook is invoked by 'git merge', which happens when a 'git pull'
184 is done on a local repository. The hook takes a single parameter, a status
185 flag specifying whether or not the merge being done was a squash merge.
186 This hook cannot affect the outcome of 'git merge' and is not executed,
187 if the merge failed due to conflicts.
188
189 This hook can be used in conjunction with a corresponding pre-commit hook to
190 save and restore any form of metadata associated with the working tree
191 (e.g.: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
192 for an example of how to do this.
193
194 pre-push
195 ~~~~~~~~
196
197 This hook is called by 'git push' and can be used to prevent a push from taking
198 place. The hook is called with two parameters which provide the name and
199 location of the destination remote, if a named remote is not being used both
200 values will be the same.
201
202 Information about what is to be pushed is provided on the hook's standard
203 input with lines of the form:
204
205 <local ref> SP <local sha1> SP <remote ref> SP <remote sha1> LF
206
207 For instance, if the command +git push origin master:foreign+ were run the
208 hook would receive a line like the following:
209
210 refs/heads/master 67890 refs/heads/foreign 12345
211
212 although the full, 40-character SHA-1s would be supplied. If the foreign ref
213 does not yet exist the `<remote SHA-1>` will be 40 `0`. If a ref is to be
214 deleted, the `<local ref>` will be supplied as `(delete)` and the `<local
215 SHA-1>` will be 40 `0`. If the local commit was specified by something other
216 than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be
217 supplied as it was originally given.
218
219 If this hook exits with a non-zero status, 'git push' will abort without
220 pushing anything. Information about why the push is rejected may be sent
221 to the user by writing to standard error.
222
223 [[pre-receive]]
224 pre-receive
225 ~~~~~~~~~~~
226
227 This hook is invoked by 'git-receive-pack' on the remote repository,
228 which happens when a 'git push' is done on a local repository.
229 Just before starting to update refs on the remote repository, the
230 pre-receive hook is invoked. Its exit status determines the success
231 or failure of the update.
232
233 This hook executes once for the receive operation. It takes no
234 arguments, but for each ref to be updated it receives on standard
235 input a line of the format:
236
237 <old-value> SP <new-value> SP <ref-name> LF
238
239 where `<old-value>` is the old object name stored in the ref,
240 `<new-value>` is the new object name to be stored in the ref and
241 `<ref-name>` is the full name of the ref.
242 When creating a new ref, `<old-value>` is 40 `0`.
243
244 If the hook exits with non-zero status, none of the refs will be
245 updated. If the hook exits with zero, updating of individual refs can
246 still be prevented by the <<update,'update'>> hook.
247
248 Both standard output and standard error output are forwarded to
249 'git send-pack' on the other end, so you can simply `echo` messages
250 for the user.
251
252 The number of push options given on the command line of
253 `git push --push-option=...` can be read from the environment
254 variable `GIT_PUSH_OPTION_COUNT`, and the options themselves are
255 found in `GIT_PUSH_OPTION_0`, `GIT_PUSH_OPTION_1`,...
256 If it is negotiated to not use the push options phase, the
257 environment variables will not be set. If the client selects
258 to use push options, but doesn't transmit any, the count variable
259 will be set to zero, `GIT_PUSH_OPTION_COUNT=0`.
260
261 See the section on "Quarantine Environment" in
262 linkgit:git-receive-pack[1] for some caveats.
263
264 [[update]]
265 update
266 ~~~~~~
267
268 This hook is invoked by 'git-receive-pack' on the remote repository,
269 which happens when a 'git push' is done on a local repository.
270 Just before updating the ref on the remote repository, the update hook
271 is invoked. Its exit status determines the success or failure of
272 the ref update.
273
274 The hook executes once for each ref to be updated, and takes
275 three parameters:
276
277 - the name of the ref being updated,
278 - the old object name stored in the ref,
279 - and the new object name to be stored in the ref.
280
281 A zero exit from the update hook allows the ref to be updated.
282 Exiting with a non-zero status prevents 'git-receive-pack'
283 from updating that ref.
284
285 This hook can be used to prevent 'forced' update on certain refs by
286 making sure that the object name is a commit object that is a
287 descendant of the commit object named by the old object name.
288 That is, to enforce a "fast-forward only" policy.
289
290 It could also be used to log the old..new status. However, it
291 does not know the entire set of branches, so it would end up
292 firing one e-mail per ref when used naively, though. The
293 <<post-receive,'post-receive'>> hook is more suited to that.
294
295 In an environment that restricts the users' access only to git
296 commands over the wire, this hook can be used to implement access
297 control without relying on filesystem ownership and group
298 membership. See linkgit:git-shell[1] for how you might use the login
299 shell to restrict the user's access to only git commands.
300
301 Both standard output and standard error output are forwarded to
302 'git send-pack' on the other end, so you can simply `echo` messages
303 for the user.
304
305 The default 'update' hook, when enabled--and with
306 `hooks.allowunannotated` config option unset or set to false--prevents
307 unannotated tags to be pushed.
308
309 [[post-receive]]
310 post-receive
311 ~~~~~~~~~~~~
312
313 This hook is invoked by 'git-receive-pack' on the remote repository,
314 which happens when a 'git push' is done on a local repository.
315 It executes on the remote repository once after all the refs have
316 been updated.
317
318 This hook executes once for the receive operation. It takes no
319 arguments, but gets the same information as the
320 <<pre-receive,'pre-receive'>>
321 hook does on its standard input.
322
323 This hook does not affect the outcome of 'git-receive-pack', as it
324 is called after the real work is done.
325
326 This supersedes the <<post-update,'post-update'>> hook in that it gets
327 both old and new values of all the refs in addition to their
328 names.
329
330 Both standard output and standard error output are forwarded to
331 'git send-pack' on the other end, so you can simply `echo` messages
332 for the user.
333
334 The default 'post-receive' hook is empty, but there is
335 a sample script `post-receive-email` provided in the `contrib/hooks`
336 directory in Git distribution, which implements sending commit
337 emails.
338
339 The number of push options given on the command line of
340 `git push --push-option=...` can be read from the environment
341 variable `GIT_PUSH_OPTION_COUNT`, and the options themselves are
342 found in `GIT_PUSH_OPTION_0`, `GIT_PUSH_OPTION_1`,...
343 If it is negotiated to not use the push options phase, the
344 environment variables will not be set. If the client selects
345 to use push options, but doesn't transmit any, the count variable
346 will be set to zero, `GIT_PUSH_OPTION_COUNT=0`.
347
348 [[post-update]]
349 post-update
350 ~~~~~~~~~~~
351
352 This hook is invoked by 'git-receive-pack' on the remote repository,
353 which happens when a 'git push' is done on a local repository.
354 It executes on the remote repository once after all the refs have
355 been updated.
356
357 It takes a variable number of parameters, each of which is the
358 name of ref that was actually updated.
359
360 This hook is meant primarily for notification, and cannot affect
361 the outcome of 'git-receive-pack'.
362
363 The 'post-update' hook can tell what are the heads that were pushed,
364 but it does not know what their original and updated values are,
365 so it is a poor place to do log old..new. The
366 <<post-receive,'post-receive'>> hook does get both original and
367 updated values of the refs. You might consider it instead if you need
368 them.
369
370 When enabled, the default 'post-update' hook runs
371 'git update-server-info' to keep the information used by dumb
372 transports (e.g., HTTP) up to date. If you are publishing
373 a Git repository that is accessible via HTTP, you should
374 probably enable this hook.
375
376 Both standard output and standard error output are forwarded to
377 'git send-pack' on the other end, so you can simply `echo` messages
378 for the user.
379
380 push-to-checkout
381 ~~~~~~~~~~~~~~~~
382
383 This hook is invoked by 'git-receive-pack' on the remote repository,
384 which happens when a 'git push' is done on a local repository, when
385 the push tries to update the branch that is currently checked out
386 and the `receive.denyCurrentBranch` configuration variable is set to
387 `updateInstead`. Such a push by default is refused if the working
388 tree and the index of the remote repository has any difference from
389 the currently checked out commit; when both the working tree and the
390 index match the current commit, they are updated to match the newly
391 pushed tip of the branch. This hook is to be used to override the
392 default behaviour.
393
394 The hook receives the commit with which the tip of the current
395 branch is going to be updated. It can exit with a non-zero status
396 to refuse the push (when it does so, it must not modify the index or
397 the working tree). Or it can make any necessary changes to the
398 working tree and to the index to bring them to the desired state
399 when the tip of the current branch is updated to the new commit, and
400 exit with a zero status.
401
402 For example, the hook can simply run `git read-tree -u -m HEAD "$1"`
403 in order to emulate 'git fetch' that is run in the reverse direction
404 with `git push`, as the two-tree form of `read-tree -u -m` is
405 essentially the same as `git checkout` that switches branches while
406 keeping the local changes in the working tree that do not interfere
407 with the difference between the branches.
408
409
410 pre-auto-gc
411 ~~~~~~~~~~~
412
413 This hook is invoked by 'git gc --auto'. It takes no parameter, and
414 exiting with non-zero status from this script causes the 'git gc --auto'
415 to abort.
416
417 post-rewrite
418 ~~~~~~~~~~~~
419
420 This hook is invoked by commands that rewrite commits (`git commit
421 --amend`, 'git-rebase'; currently 'git-filter-branch' does 'not' call
422 it!). Its first argument denotes the command it was invoked by:
423 currently one of `amend` or `rebase`. Further command-dependent
424 arguments may be passed in the future.
425
426 The hook receives a list of the rewritten commits on stdin, in the
427 format
428
429 <old-sha1> SP <new-sha1> [ SP <extra-info> ] LF
430
431 The 'extra-info' is again command-dependent. If it is empty, the
432 preceding SP is also omitted. Currently, no commands pass any
433 'extra-info'.
434
435 The hook always runs after the automatic note copying (see
436 "notes.rewrite.<command>" in linkgit:git-config[1]) has happened, and
437 thus has access to these notes.
438
439 The following command-specific comments apply:
440
441 rebase::
442 For the 'squash' and 'fixup' operation, all commits that were
443 squashed are listed as being rewritten to the squashed commit.
444 This means that there will be several lines sharing the same
445 'new-sha1'.
446 +
447 The commits are guaranteed to be listed in the order that they were
448 processed by rebase.
449
450 sendemail-validate
451 ~~~~~~~~~~~~~~~~~~
452
453 This hook is invoked by 'git send-email'. It takes a single parameter,
454 the name of the file that holds the e-mail to be sent. Exiting with a
455 non-zero status causes 'git send-email' to abort before sending any
456 e-mails.
457
458 fsmonitor-watchman
459 ~~~~~~~~~~~~~~~~~~
460
461 This hook is invoked when the configuration option core.fsmonitor is
462 set to .git/hooks/fsmonitor-watchman. It takes two arguments, a version
463 (currently 1) and the time in elapsed nanoseconds since midnight,
464 January 1, 1970.
465
466 The hook should output to stdout the list of all files in the working
467 directory that may have changed since the requested time. The logic
468 should be inclusive so that it does not miss any potential changes.
469 The paths should be relative to the root of the working directory
470 and be separated by a single NUL.
471
472 It is OK to include files which have not actually changed. All changes
473 including newly-created and deleted files should be included. When
474 files are renamed, both the old and the new name should be included.
475
476 Git will limit what files it checks for changes as well as which
477 directories are checked for untracked files based on the path names
478 given.
479
480 An optimized way to tell git "all files have changed" is to return
481 the filename '/'.
482
483 The exit status determines whether git will use the data from the
484 hook to limit its search. On error, it will fall back to verifying
485 all files and folders.
486
487 GIT
488 ---
489 Part of the linkgit:git[1] suite