git-receive-pack(1)
===================

NAME
----
git-receive-pack - Receive what is pushed into the repository


SYNOPSIS
--------
[verse]
'git receive-pack' <git-dir>

DESCRIPTION
-----------
Invoked by 'git send-pack' and updates the repository with the
information fed from the remote end.

This command is usually not invoked directly by the end user.
The UI for the protocol is on the 'git send-pack' side, and the
program pair is meant to be used to push updates to a remote
repository.  For pull operations, see linkgit:git-fetch-pack[1].

The command allows for the creation and fast-forwarding of sha1 refs
(heads/tags) on the remote end (strictly speaking, it is the
local end 'git-receive-pack' runs, but to the user who is sitting at
the send-pack end, it is updating the remote.  Confused?)

There are other real-world examples of using update and
post-update hooks found in the Documentation/howto directory.

'git-receive-pack' honours the receive.denyNonFastForwards config
option, which tells it if updates to a ref should be denied if they
are not fast-forwards.

A number of other receive.* config options are available to tweak
its behavior, see linkgit:git-config[1].

OPTIONS
-------
<git-dir>::
	The repository to sync into.

--http-backend-info-refs::
	Used by linkgit:git-http-backend[1] to serve up
	`$GIT_URL/info/refs?service=git-receive-pack` requests. See
	`--http-backend-info-refs` in linkgit:git-upload-pack[1].

--skip-connectivity-check::
	Bypasses the connectivity checks that validate the existence of all
	objects in the transitive closure of reachable objects. This option is
	intended for server operators that want to implement their own object
	connectivity validation outside of Git. This is useful in such cases
	where the server-side knows additional information about how Git is
	being used and thus can rely on certain guarantees to more efficiently
	compute object connectivity that Git itself cannot make. Usage of this
	option without a reliable external mechanism to ensure full reachable
	object connectivity risks corrupting the repository and should not be
	used in the general case.

PRE-RECEIVE HOOK
----------------
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:

       sha1-old SP sha1-new SP refname LF

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.

When accepting a signed push (see linkgit:git-push[1]), the signed
push certificate is stored in a blob and an environment variable
`GIT_PUSH_CERT` can be consulted for its object name.  See the
description of `post-receive` hook for an example.  In addition, the
certificate is verified using GPG and the result is exported with
the following environment variables:

`GIT_PUSH_CERT_SIGNER`::
	The name and the e-mail address of the owner of the key that
	signed the push certificate.

`GIT_PUSH_CERT_KEY`::
	The GPG key ID of the key that signed the push certificate.

`GIT_PUSH_CERT_STATUS`::
	The status of GPG verification of the push certificate,
	using the same mnemonic as used in `%G?` format of `git log`
	family of commands (see linkgit:git-log[1]).

`GIT_PUSH_CERT_NONCE`::
	The nonce string the process asked the signer to include
	in the push certificate.  If this does not match the value
	recorded on the "nonce" header in the push certificate, it
	may indicate that the certificate is a valid one that is
	being replayed from a separate "git push" session.

`GIT_PUSH_CERT_NONCE_STATUS`::
`UNSOLICITED`;;
	"git push --signed" sent a nonce when we did not ask it to