'\" t
.\"     Title: git-receive-pack
.\"    Author: [FIXME: author] [see http://docbook.sf.net/el/author]
.\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/>
.\"      Date: 05/28/2018
.\"    Manual: Git Manual
.\"    Source: Git 2.1.4
.\"  Language: English
.\"
.TH "GIT\-RECEIVE\-PACK" "1" "05/28/2018" "Git 2\&.1\&.4" "Git Manual"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
git-receive-pack \- Receive what is pushed into the repository
.SH "SYNOPSIS"
.sp
.nf
\fIgit\-receive\-pack\fR <directory>
.fi
.sp
.SH "DESCRIPTION"
.sp
Invoked by \fIgit send\-pack\fR and updates the repository with the information fed from the remote end\&.
.sp
This command is usually not invoked directly by the end user\&. The UI for the protocol is on the \fIgit send\-pack\fR side, and the program pair is meant to be used to push updates to remote repository\&. For pull operations, see \fBgit-fetch-pack\fR(1)\&.
.sp
The command allows for creation and fast\-forwarding of sha1 refs (heads/tags) on the remote end (strictly speaking, it is the local end \fIgit\-receive\-pack\fR runs, but to the user who is sitting at the send\-pack end, it is updating the remote\&. Confused?)
.sp
There are other real\-world examples of using update and post\-update hooks found in the Documentation/howto directory\&.
.sp
\fIgit\-receive\-pack\fR honours the receive\&.denyNonFastForwards config option, which tells it if updates to a ref should be denied if they are not fast\-forwards\&.
.SH "OPTIONS"
.PP
<directory>
.RS 4
The repository to sync into\&.
.RE
.SH "PRE-RECEIVE HOOK"
.sp
Before any ref is updated, if $GIT_DIR/hooks/pre\-receive file exists and is executable, it will be invoked once with no parameters\&. The standard input of the hook will be one line per ref to be updated:
.sp
.if n \{\
.RS 4
.\}
.nf
sha1\-old SP sha1\-new SP refname LF
.fi
.if n \{\
.RE
.\}
.sp
The refname value is relative to $GIT_DIR; e\&.g\&. for the master head this is "refs/heads/master"\&. The two sha1 values before each refname are the object names for the refname before and after the update\&. Refs to be created will have sha1\-old equal to 0{40}, while refs to be deleted will have sha1\-new equal to 0{40}, otherwise sha1\-old and sha1\-new should be valid objects in the repository\&.
.sp
This hook is called before any refname is updated and before any fast\-forward checks are performed\&.
.sp
If the pre\-receive hook exits with a non\-zero exit status no updates will be performed, and the update, post\-receive and post\-update hooks will not be invoked either\&. This can be useful to quickly bail out if the update is not to be supported\&.
.SH "UPDATE HOOK"
.sp
Before each ref is updated, if $GIT_DIR/hooks/update file exists and is executable, it is invoked once per ref, with three parameters:
.sp
.if n \{\
.RS 4
.\}
.nf
$GIT_DIR/hooks/update refname sha1\-old sha1\-new
.fi
.if n \{\
.RE
.\}
.sp
The refname parameter is relative to $GIT_DIR; e\&.g\&. for the master head this is "refs/heads/master"\&. The two sha1 arguments are the object names for the refname before and after the update\&. Note that the hook is called before the refname is updated, so either sha1\-old is 0{40} (meaning there is no such ref yet), or it should match what is recorded in refname\&.
.sp
The hook should exit with non\-zero status if it wants to disallow updating the named ref\&. Otherwise it should exit with zero\&.
.sp
Successful execution (a zero exit status) of this hook does not ensure the ref will actually be updated, it is only a prerequisite\&. As such it is not a good idea to send notices (e\&.g\&. email) from this hook\&. Consider using the post\-receive hook instead\&.
.SH "POST-RECEIVE HOOK"
.sp
After all refs were updated (or attempted to be updated), if any ref update was successful, and if $GIT_DIR/hooks/post\-receive file exists and is executable, it will be invoked once with no parameters\&. The standard input of the hook will be one line for each successfully updated ref:
.sp
.if n \{\
.RS 4
.\}
.nf
sha1\-old SP sha1\-new SP refname LF
.fi
.if n \{\
.RE
.\}
.sp
The refname value is relative to $GIT_DIR; e\&.g\&. for the master head this is "refs/heads/master"\&. The two sha1 values before each refname are the object names for the refname before and after the update\&. Refs that were created will have sha1\-old equal to 0{40}, while refs that were deleted will have sha1\-new equal to 0{40}, otherwise sha1\-old and sha1\-new should be valid objects in the repository\&.
.sp
Using this hook, it is easy to generate mails describing the updates to the repository\&. This example script sends one mail message per ref listing the commits pushed to the repository:
.sp
.if n \{\
.RS 4
.\}
.nf
#!/bin/sh
# mail out commit update information\&.
while read oval nval ref
do
        if expr "$oval" : \*(Aq0*$\*(Aq >/dev/null
        then
                echo "Created a new ref, with the following commits:"
                git rev\-list \-\-pretty "$nval"
        else
                echo "New commits:"
                git rev\-list \-\-pretty "$nval" "^$oval"
        fi |
        mail \-s "Changes to ref $ref" commit\-list@mydomain
done
exit 0
.fi
.if n \{\
.RE
.\}
.sp
The exit code from this hook invocation is ignored, however a non\-zero exit code will generate an error message\&.
.sp
Note that it is possible for refname to not have sha1\-new when this hook runs\&. This can easily occur if another user modifies the ref after it was updated by \fIgit\-receive\-pack\fR, but before the hook was able to evaluate it\&. It is recommended that hooks rely on sha1\-new rather than the current value of refname\&.
.SH "POST-UPDATE HOOK"
.sp
After all other processing, if at least one ref was updated, and if $GIT_DIR/hooks/post\-update file exists and is executable, then post\-update will be called with the list of refs that have been updated\&. This can be used to implement any repository wide cleanup tasks\&.
.sp
The exit code from this hook invocation is ignored; the only thing left for \fIgit\-receive\-pack\fR to do at that point is to exit itself anyway\&.
.sp
This hook can be used, for example, to run git update\-server\-info if the repository is packed and is served via a dumb transport\&.
.sp
.if n \{\
.RS 4
.\}
.nf
#!/bin/sh
exec git update\-server\-info
.fi
.if n \{\
.RE
.\}
.SH "SEE ALSO"
.sp
\fBgit-send-pack\fR(1), \fBgitnamespaces\fR(7)
.SH "GIT"
.sp
Part of the \fBgit\fR(1) suite