1githooks(5) 2=========== 3 4NAME 5---- 6githooks - Hooks used by git 7 8SYNOPSIS 9-------- 10$GIT_DIR/hooks/* 11 12 13DESCRIPTION 14----------- 15 16Hooks are little scripts you can place in `$GIT_DIR/hooks` 17directory to trigger action at certain points. When 18`git-init` is run, a handful example hooks are copied in the 19`hooks` directory of the new repository, but by default they are 20all disabled. To enable a hook, make it executable with `chmod +x`. 21 22This document describes the currently defined hooks. 23 24applypatch-msg 25-------------- 26 27This hook is invoked by `git-am` script. It takes a single 28parameter, the name of the file that holds the proposed commit 29log message. Exiting with non-zero status causes 30`git-am` to abort before applying the patch. 31 32The hook is allowed to edit the message file in place, and can 33be used to normalize the message into some project standard 34format (if the project has one). It can also be used to refuse 35the commit after inspecting the message file. 36 37The default 'applypatch-msg' hook, when enabled, runs the 38'commit-msg' hook, if the latter is enabled. 39 40pre-applypatch 41-------------- 42 43This hook is invoked by `git-am`. It takes no parameter, and is 44invoked after the patch is applied, but before a commit is made. 45 46If it exits with non-zero status, then the working tree will not be 47committed after applying the patch. 48 49It can be used to inspect the current working tree and refuse to 50make a commit if it does not pass certain test. 51 52The default 'pre-applypatch' hook, when enabled, runs the 53'pre-commit' hook, if the latter is enabled. 54 55post-applypatch 56--------------- 57 58This hook is invoked by `git-am`. It takes no parameter, 59and is invoked after the patch is applied and a commit is made. 60 61This hook is meant primarily for notification, and cannot affect 62the outcome of `git-am`. 63 64pre-commit 65---------- 66 67This hook is invoked by `git-commit`, and can be bypassed 68with `\--no-verify` option. It takes no parameter, and is 69invoked before obtaining the proposed commit log message and 70making a commit. Exiting with non-zero status from this script 71causes the `git-commit` to abort. 72 73The default 'pre-commit' hook, when enabled, catches introduction 74of lines with trailing whitespaces and aborts the commit when 75such a line is found. 76 77All the `git-commit` hooks are invoked with the environment 78variable `GIT_EDITOR=:` if the command will not bring up an editor 79to modify the commit message. 80 81prepare-commit-msg 82------------------ 83 84This hook is invoked by `git-commit` right after preparing the 85default log message, and before the editor is started. 86 87It takes one to three parameters. The first is the name of the file 88that the commit log message. The second is the source of the commit 89message, and can be: `message` (if a `\-m` or `\-F` option was 90given); `template` (if a `\-t` option was given or the 91configuration option `commit.template` is set); `merge` (if the 92commit is a merge or a `.git/MERGE_MSG` file exists); `squash` 93(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by 94a commit SHA1 (if a `\-c`, `\-C` or `\--amend` option was given). 95 96If the exit status is non-zero, `git-commit` will abort. 97 98The purpose of the hook is to edit the message file in place, and 99it is not suppressed by the `\--no-verify` option. A non-zero exit 100means a failure of the hook and aborts the commit. It should not 101be used as replacement for pre-commit hook. 102 103The sample `prepare-commit-msg` hook that comes with git comments 104out the `Conflicts:` part of a merge's commit message. 105 106commit-msg 107---------- 108 109This hook is invoked by `git-commit`, and can be bypassed 110with `\--no-verify` option. It takes a single parameter, the 111name of the file that holds the proposed commit log message. 112Exiting with non-zero status causes the `git-commit` to 113abort. 114 115The hook is allowed to edit the message file in place, and can 116be used to normalize the message into some project standard 117format (if the project has one). It can also be used to refuse 118the commit after inspecting the message file. 119 120The default 'commit-msg' hook, when enabled, detects duplicate 121"Signed-off-by" lines, and aborts the commit if one is found. 122 123post-commit 124----------- 125 126This hook is invoked by `git-commit`. It takes no 127parameter, and is invoked after a commit is made. 128 129This hook is meant primarily for notification, and cannot affect 130the outcome of `git-commit`. 131 132post-checkout 133----------- 134 135This hook is invoked when a `git-checkout` is run after having updated the 136worktree. The hook is given three parameters: the ref of the previous HEAD, 137the ref of the new HEAD (which may or may not have changed), and a flag 138indicating whether the checkout was a branch checkout (changing branches, 139flag=1) or a file checkout (retrieving a file from the index, flag=0). 140This hook cannot affect the outcome of `git-checkout`. 141 142This hook can be used to perform repository validity checks, auto-display 143differences from the previous HEAD if different, or set working dir metadata 144properties. 145 146post-merge 147----------- 148 149This hook is invoked by `git-merge`, which happens when a `git pull` 150is done on a local repository. The hook takes a single parameter, a status 151flag specifying whether or not the merge being done was a squash merge. 152This hook cannot affect the outcome of `git-merge` and is not executed, 153if the merge failed due to conflicts. 154 155This hook can be used in conjunction with a corresponding pre-commit hook to 156save and restore any form of metadata associated with the working tree 157(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl 158for an example of how to do this. 159 160[[pre-receive]] 161pre-receive 162----------- 163 164This hook is invoked by `git-receive-pack` on the remote repository, 165which happens when a `git push` is done on a local repository. 166Just before starting to update refs on the remote repository, the 167pre-receive hook is invoked. Its exit status determines the success 168or failure of the update. 169 170This hook executes once for the receive operation. It takes no 171arguments, but for each ref to be updated it receives on standard 172input a line of the format: 173 174 <old-value> SP <new-value> SP <ref-name> LF 175 176where `<old-value>` is the old object name stored in the ref, 177`<new-value>` is the new object name to be stored in the ref and 178`<ref-name>` is the full name of the ref. 179When creating a new ref, `<old-value>` is 40 `0`. 180 181If the hook exits with non-zero status, none of the refs will be 182updated. If the hook exits with zero, updating of individual refs can 183still be prevented by the <<update,'update'>> hook. 184 185Both standard output and standard error output are forwarded to 186`git-send-pack` on the other end, so you can simply `echo` messages 187for the user. 188 189[[update]] 190update 191------ 192 193This hook is invoked by `git-receive-pack` on the remote repository, 194which happens when a `git push` is done on a local repository. 195Just before updating the ref on the remote repository, the update hook 196is invoked. Its exit status determines the success or failure of 197the ref update. 198 199The hook executes once for each ref to be updated, and takes 200three parameters: 201 202 - the name of the ref being updated, 203 - the old object name stored in the ref, 204 - and the new objectname to be stored in the ref. 205 206A zero exit from the update hook allows the ref to be updated. 207Exiting with a non-zero status prevents `git-receive-pack` 208from updating that ref. 209 210This hook can be used to prevent 'forced' update on certain refs by 211making sure that the object name is a commit object that is a 212descendant of the commit object named by the old object name. 213That is, to enforce a "fast forward only" policy. 214 215It could also be used to log the old..new status. However, it 216does not know the entire set of branches, so it would end up 217firing one e-mail per ref when used naively, though. The 218<<post-receive,'post-receive'>> hook is more suited to that. 219 220Another use suggested on the mailing list is to use this hook to 221implement access control which is finer grained than the one 222based on filesystem group. 223 224Both standard output and standard error output are forwarded to 225`git-send-pack` on the other end, so you can simply `echo` messages 226for the user. 227 228The default 'update' hook, when enabled--and with 229`hooks.allowunannotated` config option turned on--prevents 230unannotated tags to be pushed. 231 232[[post-receive]] 233post-receive 234------------ 235 236This hook is invoked by `git-receive-pack` on the remote repository, 237which happens when a `git push` is done on a local repository. 238It executes on the remote repository once after all the refs have 239been updated. 240 241This hook executes once for the receive operation. It takes no 242arguments, but gets the same information as the 243<<pre-receive,'pre-receive'>> 244hook does on its standard input. 245 246This hook does not affect the outcome of `git-receive-pack`, as it 247is called after the real work is done. 248 249This supersedes the <<post-update,'post-update'>> hook in that it gets 250both old and new values of all the refs in addition to their 251names. 252 253Both standard output and standard error output are forwarded to 254`git-send-pack` on the other end, so you can simply `echo` messages 255for the user. 256 257The default 'post-receive' hook is empty, but there is 258a sample script `post-receive-email` provided in the `contrib/hooks` 259directory in git distribution, which implements sending commit 260emails. 261 262[[post-update]] 263post-update 264----------- 265 266This hook is invoked by `git-receive-pack` on the remote repository, 267which happens when a `git push` is done on a local repository. 268It executes on the remote repository once after all the refs have 269been updated. 270 271It takes a variable number of parameters, each of which is the 272name of ref that was actually updated. 273 274This hook is meant primarily for notification, and cannot affect 275the outcome of `git-receive-pack`. 276 277The 'post-update' hook can tell what are the heads that were pushed, 278but it does not know what their original and updated values are, 279so it is a poor place to do log old..new. The 280<<post-receive,'post-receive'>> hook does get both original and 281updated values of the refs. You might consider it instead if you need 282them. 283 284When enabled, the default 'post-update' hook runs 285`git-update-server-info` to keep the information used by dumb 286transports (e.g., HTTP) up-to-date. If you are publishing 287a git repository that is accessible via HTTP, you should 288probably enable this hook. 289 290Both standard output and standard error output are forwarded to 291`git-send-pack` on the other end, so you can simply `echo` messages 292for the user. 293 294pre-auto-gc 295----------- 296 297This hook is invoked by `git-gc --auto`. It takes no parameter, and 298exiting with non-zero status from this script causes the `git-gc --auto` 299to abort. 300 301GIT 302--- 303Part of the linkgit:git[1] suite