SYNOPSIS

git receive-pack <git-dir>

DESCRIPTION

git send-pack によって呼び出され、リモート側からもたらされた情報でリポジトリを更新します。

このコマンドは通常、エンドユーザーによって直接呼び出されることはありません。 プロトコルのUIは git send-pack 側にあり、プログラムペアは更新をリモートリポジトリにプッシュするために使用されることを目的としています。 プル操作については、 git-fetch-pack(1) を参照してください。

このコマンドを使用すると、リモート側で sha1 ref (ヘッド/タグ)を作成して早送りできます(厳密に言えば、ローカル側では git-receive-pack が実行されますが、send-pack側に居るユーザにとってはリモートの更新をしている事になります。混乱しないでね？)

Documentation/howtoディレクトリには、更新フック(update hook)と更新後フック(post-update hook)を使用した実例が他にもあります。

git-receive-pack は、 receive.denyNonFastForwards 構成オプションを尊重します。このオプションは、refの更新が早送りでない場合に拒否する必要があるかどうかを通知します。

他の多くの receive.* 構成オプションを使用して、その動作を微調整できます。 git-config(1) を参照してください。

OPTIONS

<git-dir>

同期するリポジトリ。

--http-backend-info-refs

git-http-backend(1) が、 $GIT_URL/info/refs?service=git-receive-pack リクエストを処理するために使用します。 git-upload-pack(1) の --http-backend-info-refs を参照してください。

PRE-RECEIVE HOOK

refが更新される前に、 $GIT_DIR/hooks/pre-receive ファイルが存在し、実行可能である場合、パラメーターなしで1回呼び出されます。 フックの標準入力は、更新される参照ごとに1行になります:

sha1-old SP sha1-new SP refname LF

refnameの値は$GIT_DIRを基準にしています。 例えば masterヘッドの場合、これは refs/heads/master です。 各refnameの前の2つのsha1値は、更新前後のrefnameのオブジェクト名です。 作成されるrefのsha1-oldは 0{40} に等しく、削除されるrefのsha1-newは 0{40} になります。それ以外の場合、sha1-oldとsha1-newはリポジトリ内の有効なオブジェクトである必要があります。

署名されたプッシュを受け入れる場合(git-push(1) 参照)、署名されたプッシュ証明書はブロブに格納され、環境変数 GIT_PUSH_CERT でオブジェクト名を調べることができます。 例については、 post-receive フックの説明を参照してください。 さらに、証明書はGPGを使用して検証され、結果は以下の環境変数とともにエクスポートされます:

GIT_PUSH_CERT_SIGNER

プッシュ証明書に署名したキーの所有者の、名前(name)と電子メールアドレス(e-mail address)。

GIT_PUSH_CERT_KEY

プッシュ証明書に署名したキーのGPGキーID。

GIT_PUSH_CERT_STATUS

コマンドの git log ファミリーの %G? 形式で使用されるのと同一のニーモニックを使用した、プッシュ証明書のGPG検証のステータス(git-log(1) を参照)。

GIT_PUSH_CERT_NONCE

プロセスが署名者にプッシュ証明書に含めるように要求したノンス(nonce;その場限りの)文字列。これがプッシュ証明書の「nonce」ヘッダーに記録されている値と一致しない場合は、証明書が別の git push セッションから再実行されている有効な証明書であることを示している可能性があります。

GIT_PUSH_CERT_NONCE_STATUS
UNSOLICITED

git push --signed は、私達が送信を問い合わせなかったときにノンス(nonce)を送信しました。

MISSING

git push --signed はノンスヘッダーを送信しませんでした。

BAD

git push --signed は偽のノンスを送信しました。

OK

git push --signed は、私達が送信を要求したノンスを送信しました。

SLOP

git push --signed は、前回のセッションで送信するように要求したものとは異なるノンスを送信しました。 GIT_PUSH_CERT_NONCE_SLOP 環境変数を参照してください。

GIT_PUSH_CERT_NONCE_SLOP

git push --signed は、現在送信するように要求したものとは異なるノンスを送信しました。開始時刻が現在のセッションとは何秒も違う別のセッションで送信されました。 GIT_PUSH_CERT_NONCE_STATUS が SLOP と言った場合にのみ意味があります。 git-config(1) の receive.certNonceSlop 変数についてもお読みください。

このフックは、refnameが更新される前、および早送りチェックが実行される前に呼び出されます。

受信前(pre-receive)フックがゼロ以外の終了ステータスで終了した場合、更新は実行されず、更新(update)フックや受信後フック(post-receive)や更新後(post-update)フックも呼び出されません。 これは、更新がサポートされない場合に迅速に救済するのに役立ちます。

以下の検疫環境(quarantine environment)に関する注記を参照してください。

UPDATE HOOK

各refが更新される前に、 $GIT_DIR/hooks/update ファイルが存在し、実行可能である場合、3つのパラメーターを使用してrefごとに1回呼び出されます:

$GIT_DIR/hooks/update refname sha1-old sha1-new

refnameパラメーターは$GIT_DIRに関連しています。 例えば masterヘッドの場合、これは refs/heads/master です。 2つのsha1引数は、更新前後のrefnameのオブジェクト名です。 refnameが更新される前にフックが呼び出されるため、sha1-oldが 0{40} (そのようなrefがまだないことを意味します)であるか、refnameに記録されているものと一致する必要があることに注意してください。

名前付きrefの更新を禁止する場合、フックはゼロ以外のステータスで終了する必要があります。 それ以外の場合は、ゼロで終了する必要があります。

このフックの正常な実行(ゼロ終了ステータス)は、refが実際に更新されることを保証するものではなく、前提条件にすぎません。 そのため、このフックから通知(電子メールなど)を送信することはお勧めできません。 代わりに、受信後(post-receive)フックの使用を検討してください。

POST-RECEIVE HOOK

すべてのrefが更新された後(または更新が試みられた後)、refの更新が成功した場合、および $GIT_DIR/hooks/post-receive ファイルが存在し、実行可能である場合、パラメーターなしで1回呼び出されます。 フックの標準入力は、正常に更新された参照ごとに1行になります。

sha1-old SP sha1-new SP refname LF

refnameの値は$GIT_DIRを基準にしています。 例えば masterヘッドの場合、これは refs/heads/master です。 各refnameの前の2つのsha1値は、更新前後のrefnameのオブジェクト名です。 作成された参照はsha1-oldが 0{40} に等しくなり、削除された参照はsha1-newが 0{40} に等しくなります。それ以外の場合、sha1-oldとsha1-newはリポジトリ内の有効なオブジェクトである必要があります。

署名されたプッシュを受け入れた後、 pre-receive フックの場合と同様に、 GIT_PUSH_CERT* 環境変数を検査できます。

このフックを使用すると、リポジトリの更新を説明するメールを簡単に生成できます。 このサンプルスクリプトは、リポジトリにプッシュされたコミットを一覧表示するrefごとに1つのメールメッセージを送信し、適切な署名を持つ署名付きプッシュのプッシュ証明書をログ取りサービス(logger service)に記録します:

#!/bin/sh
# mail out commit update information.
while read oval nval ref
do
        if expr "$oval" : '0*$' >/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
# log signed push certificate, if any
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
        (
                echo expected nonce is ${GIT_PUSH_NONCE}
                git cat-file blob ${GIT_PUSH_CERT}
        ) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

このフック呼び出しからの終了コードは無視されますが、ゼロ以外の終了コードはエラーメッセージを生成します。

このフックが実行されると、refnameにsha1-newがない可能性があることに注意してください。 これは、 git-receive-pack によって更新された後、フックがそれを評価できるようになる前に、別のユーザーが参照を変更した場合に簡単に発生する可能性があります。 フックは、refnameの現在の値ではなく、sha1-newに依存することをお勧めします。

POST-UPDATE HOOK

他のすべての処理の後、少なくとも1つのrefが更新され、 $GIT_DIR/hooks/post-update ファイルが存在し、実行可能である場合、更新されたrefのリストを使用してpost-updateが呼び出されます。 これは、リポジトリ全体のクリーンアップタスクを実装するために使用できます。

このフック呼び出しからの終了コードは無視されます。 その時点で git-receive-pack に残されているのは、とにかく自分自身を終了することだけです。

このフックは、たとえば、リポジトリがパックされてバカ転送(dumb transport)を介して提供される場合に git update-server-info を実行するために使用できます。

#!/bin/sh
exec git update-server-info

QUARANTINE ENVIRONMENT

receive-pack がオブジェクトを取り込むと、それらは $GIT_DIR/objects ディレクトリ内の一時的な「隔離」(quarantine)ディレクトリに配置され、 pre-receive フックが完了した後にのみメインオブジェクトストアに移行されます。 それ以前にプッシュが失敗した場合、一時ディレクトリは完全に削除されます。

これには、ユーザーからも見えるいくつかの影響と注意事項があります:

  1. 着信パックの問題、またはオブジェクトの欠落、または pre-receive フックが原因で失敗したプッシュは、ディスク上のデータを残しません。 これは通常、繰り返し失敗したプッシュがディスクをいっぱいにするのを防ぐのに役立ちますが、デバッグがより困難になる可能性があります。

  2. pre-receive フックによって作成されたオブジェクトはすべて、隔離(quarantine)ディレクトリに作成されます(成功した場合にのみ移行されます)。

  3. pre-receive フックは、隔離(quarantined)されたオブジェクトを指すように参照を更新してはなりません。 リポジトリにアクセスする他のプログラムはオブジェクトを見ることができません(そして、受信前(pre-receive)フックが失敗した場合、それらのrefは破損します)。 安全のため、 pre-receive 内からのrefの更新は自動的に拒否されます。

SEE ALSO

git-send-pack(1), gitnamespaces(7)

GIT

Part of the git(1) suite