SYNOPSIS

git-upload-pack [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
                  [--advertise-refs] <directory>

DESCRIPTION

git fetch-pack によって呼び出され、通信の反対側で欠落しているオブジェクトを調べ、パッキング後にそれらを送信します。

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

OPTIONS

--[no-]strict

<directory> がGitディレクトリでない場合、 <directory>/.git/ を試さない。

--timeout=<n>

非アクティブになった <n> 秒後に転送を中断します。

--stateless-rpc

stdinとstdoutを使用して 読み取り/書き込み サイクルを1回だけ実行します。これは、プログラムが要求を読み取り、応答を書き込み、終了する必要があるHTTP POST要求処理モデルに適合します。

--http-backend-info-refs

$GIT_URL/info/refs?service=git-upload-pack リクエストを処理するために git-http-backend(1) によって使用されます。 gitprotocol-http(5) の「Smart Clients」と gitprotocol-v2(5) ドキュメントの「HTTP Transport」を参照してください。 git-receive-pack(1) でも理解されます。

<directory>

同期元のリポジトリ。

ENVIRONMENT

GIT_PROTOCOL

ワイヤープロトコルをハンドシェイクするために使用される内部変数。サーバー管理者は、この変数を渡すことができるようにいくつかのトランスポートを構成する必要がある場合があります。 git(1) のdiscussionを参照してください。

GIT_NO_LAZY_FETCH

部分(partial)リポジトリー(つまり、--filter を使用してクローンされたもの)からクローンまたはフェッチを行う際、 サーバー側の upload-pack はリクエストを完了するために上流(upstream)から追加のオブジェクトをフェッチする必要がある場合があります。 デフォルトでは、 upload-pack はそのような遅延フェッチを実行することを拒否します。 なぜなら、 git fetch はソース・リポジトリーの設定やフックで指定された任意のコマンドを実行する可能性があり、 upload-pack は信頼できない .git ディレクトリでも安全に実行できるように設計されているためです。

これは、upload-pack が内部的に GIT_NO_LAZY_FETCH 変数を 1 に設定することで実装されています。 もしこれを上書きしたい場合(部分クローン(partial clone)からフェッチしており、 あなたが信頼できると確信している場合)、 GIT_NO_LAZY_FETCH を明示的に 0 に設定することができます。

SECURITY

ほとんどの Git コマンドは、 信頼できない .git ディレクトリで実行すべきではありません(git(1) の「SECURITY」セクション参照)。 upload-pack は、提供しているリポジトリーの危険な設定オプションやフックを回避しようとするため、 信頼できないディレクトリをクローンして、 そのクローン上でコマンドを実行するのが安全です。

さらなる安全性を確保するために、 upload-pack を別のユーザーとして実行できる場合があります。 詳細はプラットフォームに依存しますが、 多くのシステムでは以下のように実行できます:

git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...

SEE ALSO

gitnamespaces(7)

GIT

Part of the git(1) suite