設定和配置
獲取和建立專案
基本快照
分支與合併
共享和更新專案
檢查和比較
打補丁
除錯
電子郵件
外部系統
伺服器管理
- 2.45.2 → 2.50.1 無變更
-
2.45.1
2024-04-29
- 2.45.0 無更改
- 2.44.2 → 2.44.4 無變更
-
2.44.1
2024-04-19
- 2.44.0 無變更
- 2.43.5 → 2.43.7 無變更
-
2.43.4
2024-04-19
- 2.43.1 → 2.43.3 無變更
- 2.43.0 無變更
- 2.42.3 → 2.42.4 無變更
-
2.42.2
2024-04-19
- 2.42.1 無變更
- 2.42.0 無變更
- 2.41.2 → 2.41.3 無變更
-
2.41.1
2024-04-19
- 2.41.0 無變更
- 2.40.3 → 2.40.4 無變更
-
2.40.2
2024-04-19
- 2.40.1 無變更
- 2.40.0 無變更
- 2.39.5 無更改
-
2.39.4
2024-04-19
- 2.38.1 → 2.39.3 無變更
-
2.38.0
2022-10-02
- 2.34.1 → 2.37.7 無更改
-
2.34.0
2021-11-15
- 2.21.1 → 2.33.8 無變更
- 2.21.0 無變更
- 2.19.3 → 2.20.5 無更改
-
2.19.2
2018-11-21
- 2.11.4 → 2.19.1 無變更
-
2.10.5
2017-09-22
- 2.1.4 → 2.9.5 無更改
-
2.0.5
2014-12-17
描述
由 git fetch-pack 呼叫，它會了解對方缺少哪些物件，並在打包後傳送它們。
此命令通常不由終端使用者直接呼叫。該協議的使用者介面在 git fetch-pack 一側，這對程式旨在用於從遠端倉庫拉取更新。對於推送操作，請參閱 git send-pack。
選項
- --[no-]strict
-
如果 <directory> 不是 Git 倉庫，則不要嘗試 <directory>/.git/。
- --timeout=<n>
-
在 <n> 秒不活動後中斷傳輸。
- --stateless-rpc
-
僅對標準輸入和標準輸出執行一次讀寫迴圈。這符合 HTTP POST 請求處理模型，在該模型中，程式可以讀取請求、寫入響應並必須退出。
- --http-backend-info-refs
-
由 git-http-backend[1] 使用，用於處理 $GIT_URL/info/refs?service=git-upload-pack 請求。請參閱 gitprotocol-http[5] 中的“智慧客戶端”和 gitprotocol-v2[5] 文件中的“HTTP 傳輸”。git-receive-pack[1] 也理解此選項。
- <directory>
-
要從中同步的倉庫。
環境變數
GIT_PROTOCOL-
用於握手線路協議的內部變數。伺服器管理員可能需要配置某些傳輸方式以允許此變數傳遞。請參閱 git[1] 中的討論。
GIT_NO_LAZY_FETCH-
當從一個部分倉庫（即其本身使用
--filter克隆的倉庫）克隆或獲取時，伺服器端的upload-pack可能需要從其上游獲取額外的物件以完成請求。預設情況下，upload-pack將拒絕執行此類“惰性獲取”，因為gitfetch可能會執行源倉庫配置和鉤子中指定的任意命令（而upload-pack即使在不受信任的.git目錄中也力求安全執行）。這是透過讓
upload-pack內部將GIT_NO_LAZY_FETCH變數設定為1來實現的。如果您想覆蓋它（因為您正在從一個部分克隆中獲取，並且您確信您信任它），您可以明確地將GIT_NO_LAZY_FETCH設定為0。
安全性
大多數 Git 命令不應在不受信任的 .git 目錄中執行（請參閱 git[1] 中的 SECURITY 部分）。upload-pack 試圖避免使用其所服務倉庫中的任何危險配置選項或鉤子，從而使其可以安全地克隆不受信任的目錄並在生成的克隆上執行命令。
為了額外的安全級別，您可以嘗試以備用使用者身份執行 upload-pack。具體細節將取決於平臺，但在許多系統中，您可以執行
git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...
