1git-receive-pack(1) 2=================== 3 4NAME 5---- 6git-receive-pack - Receive what is pushed into the repository 7 8 9SYNOPSIS 10-------- 11[verse] 12'git-receive-pack' <directory> 13 14DESCRIPTION 15----------- 16Invoked by 'git send-pack' and updates the repository with the 17information fed from the remote end. 18 19This command is usually not invoked directly by the end user. 20The UI for the protocol is on the 'git send-pack' side, and the 21program pair is meant to be used to push updates to remote 22repository. For pull operations, see linkgit:git-fetch-pack[1]. 23 24The command allows for creation and fast-forwarding of sha1 refs 25(heads/tags) on the remote end (strictly speaking, it is the 26local end 'git-receive-pack' runs, but to the user who is sitting at 27the send-pack end, it is updating the remote. Confused?) 28 29There are other real-world examples of using update and 30post-update hooks found in the Documentation/howto directory. 31 32'git-receive-pack' honours the receive.denyNonFastForwards config 33option, which tells it if updates to a ref should be denied if they 34are not fast-forwards. 35 36OPTIONS 37------- 38<directory>:: 39 The repository to sync into. 40 41pre-receive Hook 42---------------- 43Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists 44and is executable, it will be invoked once with no parameters. The 45standard input of the hook will be one line per ref to be updated: 46 47 sha1-old SP sha1-new SP refname LF 48 49The refname value is relative to $GIT_DIR; e.g. for the master 50head this is "refs/heads/master". The two sha1 values before 51each refname are the object names for the refname before and after 52the update. Refs to be created will have sha1-old equal to 0\{40}, 53while refs to be deleted will have sha1-new equal to 0\{40}, otherwise 54sha1-old and sha1-new should be valid objects in the repository. 55 56When accepting a signed push (see linkgit:git-push[1]), the signed 57push certificate is stored in a blob and an environment variable 58`GIT_PUSH_CERT` can be consulted for its object name. See the 59description of `post-receive` hook for an example. 60 61This hook is called before any refname is updated and before any 62fast-forward checks are performed. 63 64If the pre-receive hook exits with a non-zero exit status no updates 65will be performed, and the update, post-receive and post-update 66hooks will not be invoked either. This can be useful to quickly 67bail out if the update is not to be supported. 68 69update Hook 70----------- 71Before each ref is updated, if $GIT_DIR/hooks/update file exists 72and is executable, it is invoked once per ref, with three parameters: 73 74 $GIT_DIR/hooks/update refname sha1-old sha1-new 75 76The refname parameter is relative to $GIT_DIR; e.g. for the master 77head this is "refs/heads/master". The two sha1 arguments are 78the object names for the refname before and after the update. 79Note that the hook is called before the refname is updated, 80so either sha1-old is 0\{40} (meaning there is no such ref yet), 81or it should match what is recorded in refname. 82 83The hook should exit with non-zero status if it wants to disallow 84updating the named ref. Otherwise it should exit with zero. 85 86Successful execution (a zero exit status) of this hook does not 87ensure the ref will actually be updated, it is only a prerequisite. 88As such it is not a good idea to send notices (e.g. email) from 89this hook. Consider using the post-receive hook instead. 90 91post-receive Hook 92----------------- 93After all refs were updated (or attempted to be updated), if any 94ref update was successful, and if $GIT_DIR/hooks/post-receive 95file exists and is executable, it will be invoked once with no 96parameters. The standard input of the hook will be one line 97for each successfully updated ref: 98 99 sha1-old SP sha1-new SP refname LF 100 101The refname value is relative to $GIT_DIR; e.g. for the master 102head this is "refs/heads/master". The two sha1 values before 103each refname are the object names for the refname before and after 104the update. Refs that were created will have sha1-old equal to 1050\{40}, while refs that were deleted will have sha1-new equal to 1060\{40}, otherwise sha1-old and sha1-new should be valid objects in 107the repository. 108 109The `GIT_PUSH_CERT` environment variable can be inspected, just as 110in `pre-receive` hook, after accepting a signed push. 111 112Using this hook, it is easy to generate mails describing the updates 113to the repository. This example script sends one mail message per 114ref listing the commits pushed to the repository, and logs the push 115certificates of signed pushes to a logger 116service: 117 118 #!/bin/sh 119 # mail out commit update information. 120 while read oval nval ref 121 do 122 if expr "$oval" : '0*$' >/dev/null 123 then 124 echo "Created a new ref, with the following commits:" 125 git rev-list --pretty "$nval" 126 else 127 echo "New commits:" 128 git rev-list --pretty "$nval" "^$oval" 129 fi | 130 mail -s "Changes to ref $ref" commit-list@mydomain 131 done 132 # log signed push certificate, if any 133 if test -n "${GIT_PUSH_CERT-}" 134 then 135 ( 136 git cat-file blob ${GIT_PUSH_CERT} 137 ) | mail -s "push certificate" push-log@mydomain 138 fi 139 exit 0 140 141The exit code from this hook invocation is ignored, however a 142non-zero exit code will generate an error message. 143 144Note that it is possible for refname to not have sha1-new when this 145hook runs. This can easily occur if another user modifies the ref 146after it was updated by 'git-receive-pack', but before the hook was able 147to evaluate it. It is recommended that hooks rely on sha1-new 148rather than the current value of refname. 149 150post-update Hook 151---------------- 152After all other processing, if at least one ref was updated, and 153if $GIT_DIR/hooks/post-update file exists and is executable, then 154post-update will be called with the list of refs that have been updated. 155This can be used to implement any repository wide cleanup tasks. 156 157The exit code from this hook invocation is ignored; the only thing 158left for 'git-receive-pack' to do at that point is to exit itself 159anyway. 160 161This hook can be used, for example, to run `git update-server-info` 162if the repository is packed and is served via a dumb transport. 163 164 #!/bin/sh 165 exec git update-server-info 166 167 168SEE ALSO 169-------- 170linkgit:git-send-pack[1], linkgit:gitnamespaces[7] 171 172GIT 173--- 174Part of the linkgit:git[1] suite