設定與配置
取得與建立專案
基本快照
分支與合併
分享與更新專案
檢查與比較
修補
除錯
電子郵件
外部系統
伺服器管理
指南
管理
底層命令
- 2.45.1 → 2.47.0 無變更
-
2.45.0
04/29/24
- 2.44.1 → 2.44.2 無變更
-
2.44.0
02/23/24
- 2.43.1 → 2.43.5 無變更
-
2.43.0
11/20/23
- 2.40.1 → 2.42.3 無變更
-
2.40.0
03/12/23
- 2.38.1 → 2.39.5 無變更
-
2.38.0
10/02/22
描述
本文檔介紹 Git 線路協定版本 2 的規格。協定 v2 將在以下方面改進 v1
-
單一服務將支援多個命令,而不是多個服務名稱
-
由於功能已移至協定的獨立區段,不再隱藏在 NUL 位元組之後,也不再受限於 pkt-line 的大小,因此更容易擴充
-
將隱藏在 NUL 位元組之後的其他資訊分離出來(例如,將代理程式字串當作功能,並且可以使用 ls-refs 來要求符號參照)
-
除非明確要求,否則將省略參考宣告
-
ls-refs 命令可明確要求某些參考
-
設計時考慮到 HTTP 和無狀態 RPC。透過明確的清除語意,HTTP 遠端輔助程式可以簡單地作為 Proxy
在協定 v2 中,通訊是以命令為導向。當第一次聯絡伺服器時,會宣告功能清單。其中某些功能會是客戶端可以要求執行的命令。一旦命令完成,客戶端可以重複使用連線並要求執行其他命令。
封包行框架
所有通訊都使用封包行框架完成,就像 v1 一樣。如需更多資訊,請參閱 gitprotocol-pack[5] 和 gitprotocol-common[5]。
在協定 v2 中,這些特殊封包將具有以下語意
-
0000 清除封包 (flush-pkt) - 表示訊息的結尾
-
0001 分隔符號封包 (delim-pkt) - 分隔訊息的區段
-
0002 回應結束封包 (response-end-pkt) - 表示無狀態連線的回應結尾
初始客戶端請求
一般而言,客戶端可以透過傳送 version=2
至所使用的傳輸的個別邊通道來要求使用協定 v2,這將不可避免地設定 GIT_PROTOCOL
。如需更多資訊,請參閱 gitprotocol-pack[5] 和 gitprotocol-http[5],以及 git.txt
中的 GIT_PROTOCOL
定義。在所有情況下,伺服器的回應都是功能宣告。
Git 傳輸
當使用 git:// 傳輸時,您可以傳送「version=2」作為額外參數來要求使用協定 v2
003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0
HTTP 傳輸
當使用 http:// 或 https:// 傳輸時,客戶端會如 gitprotocol-http[5] 中所述,發出「智慧型」info/refs 請求,並在 Git-Protocol
標頭中提供「version=2」來要求使用 v2。
C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 C: Git-Protocol: version=2
v2 伺服器將回覆
S: 200 OK S: <Some headers> S: ... S: S: 000eversion 2\n S: <capability-advertisement>
後續請求則會直接傳送到服務 $GIT_URL/git-upload-pack
。(這適用於 git-receive-pack)。
使用 git-upload-pack[1] 的 --http-backend-info-refs
選項。
可能需要設定伺服器,以透過 GIT_PROTOCOL
變數傳遞此標頭的內容。請參閱 git-http-backend.txt
中的討論。
功能宣告
決定使用協定版本 2 通訊 (根據客戶端的請求) 的伺服器,會透過在其初始回應中傳送版本字串,然後宣告其功能,來通知客戶端。每個功能都是一個具有選擇性值的金鑰。客戶端必須忽略所有未知的金鑰。未知值的語意留給每個金鑰的定義。某些功能會描述客戶端可以要求執行的命令。
capability-advertisement = protocol-version capability-list flush-pkt
protocol-version = PKT-LINE("version 2" LF) capability-list = *capability capability = PKT-LINE(key[=value] LF)
key = 1*(ALPHA | DIGIT | "-_") value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")
命令請求
在收到功能宣告後,客戶端可以發出請求,以選取它想要的命令,以及任何特定的功能或引數。然後會有一個選擇性區段,讓客戶端可以提供任何命令特定的參數或查詢。一次只能要求一個命令。
request = empty-request | command-request empty-request = flush-pkt command-request = command capability-list delim-pkt command-args flush-pkt command = PKT-LINE("command=" key LF) command-args = *command-specific-arg
command-specific-args are packet line framed arguments defined by each individual command.
然後,伺服器會檢查以確保客戶端的請求包含有效的命令以及宣告過的有效功能。如果請求有效,伺服器就會執行該命令。伺服器必須等待直到收到客戶端的整個請求,才會發出回應。回應的格式由執行的命令決定,但在所有情況下,flush-pkt 表示回應的結尾。
當命令完成,且客戶端收到來自伺服器的完整回應時,客戶端可以要求執行另一個命令,或終止連線。客戶端可以選擇性地傳送僅由 flush-pkt 組成的空請求,以表示不會再發出任何請求。
功能
功能有兩種不同的類型:一般功能,可用於傳達資訊或變更請求的行為;以及命令,這是客戶端想要執行的核心動作(提取、推送等)。
協定版本 2 預設為無狀態。這表示所有命令都必須僅持續一輪,並且從伺服器端的角度來看是無狀態的,除非客戶端已要求功能指出伺服器應維護狀態。客戶端不得要求伺服器端進行狀態管理,才能正常運作。這允許伺服器端進行簡單的輪循負載平衡,而無需擔心狀態管理。
agent
伺服器可以使用值 X
(格式為 agent=X
) 宣告 agent
功能,以通知客戶端伺服器正在執行版本 X
。客戶端可以選擇性地在其向伺服器發出的請求中,包含具有值 Y
(格式為 agent=Y
) 的 agent
功能,來傳送自己的代理程式字串 (但如果伺服器未宣告 agent 功能,則不得執行此動作)。X
和 Y
字串可以包含任何可列印的 ASCII 字元,但空格除外(也就是說,位元組範圍 32 < x < 127),而且通常採用「套件/版本」的格式(例如,「git/1.8.3.1」)。代理程式字串僅供統計和除錯之用,不得用於以程式設計方式假設特定功能的有無。
ls-refs
ls-refs
是用於在 v2 中要求參考宣告的命令。與目前的參考宣告不同,ls-refs 會接收引數,這些引數可用於限制從伺服器傳送的參考。
基本命令中不支援的其他功能將以功能宣告中命令值的形式,以空格分隔的功能清單宣告:「<command>=<feature-1> <feature-2>」
ls-refs 接受以下引數
symrefs In addition to the object pointed by it, show the underlying ref pointed by it when showing a symbolic ref. peel Show peeled tags. ref-prefix <prefix> When specified, only references having a prefix matching one of the provided prefixes are displayed. Multiple instances may be given, in which case references matching any prefix will be shown. Note that this is purely for optimization; a server MAY show refs not matching the prefix if it chooses, and clients should filter the result themselves.
如果宣告了 unborn 功能,則可以在客戶端的請求中包含以下引數。
unborn The server will send information about HEAD even if it is a symref pointing to an unborn branch in the form "unborn HEAD symref-target:<target>".
ls-refs 的輸出如下
output = *ref flush-pkt obj-id-or-unborn = (obj-id | "unborn") ref = PKT-LINE(obj-id-or-unborn SP refname *(SP ref-attribute) LF) ref-attribute = (symref | peeled) symref = "symref-target:" symref-target peeled = "peeled:" obj-id
fetch
fetch
是在 v2 中用來提取 packfile 的指令。它可以被視為 v1 fetch 的修改版本,其中參考廣告(ref-advertisement)被移除(因為 ls-refs
指令負責此功能),並且訊息格式經過調整,以消除冗餘並允許輕鬆添加未來的擴展。
基本命令中不支援的其他功能將以功能宣告中命令值的形式,以空格分隔的功能清單宣告:「<command>=<feature-1> <feature-2>」
一個 fetch
請求可以接受以下參數:
want <oid> Indicates to the server an object which the client wants to retrieve. Wants can be anything and are not limited to advertised objects.
have <oid> Indicates to the server an object which the client has locally. This allows the server to make a packfile which only contains the objects that the client needs. Multiple 'have' lines can be supplied.
done Indicates to the server that negotiation should terminate (or not even begin if performing a clone) and that the server should use the information supplied in the request to construct the packfile.
thin-pack Request that a thin pack be sent, which is a pack with deltas which reference base objects not contained within the pack (but are known to exist at the receiving end). This can reduce the network traffic significantly, but it requires the receiving end to know how to "thicken" these packs by adding the missing bases to the pack.
no-progress Request that progress information that would normally be sent on side-band channel 2, during the packfile transfer, should not be sent. However, the side-band channel 3 is still used for error responses.
include-tag Request that annotated tags should be sent if the objects they point to are being sent.
ofs-delta Indicate that the client understands PACKv2 with delta referring to its base by position in pack rather than by an oid. That is, they can read OBJ_OFS_DELTA (aka type 6) in a packfile.
如果宣告了 shallow 功能,則以下參數可以包含在客戶端的請求中,並且伺服器的回應中可能會加入 shallow-info 區段,如下所述。
shallow <oid> A client must notify the server of all commits for which it only has shallow copies (meaning that it doesn't have the parents of a commit) by supplying a 'shallow <oid>' line for each such object so that the server is aware of the limitations of the client's history. This is so that the server is aware that the client may not have all objects reachable from such commits.
deepen <depth> Requests that the fetch/clone should be shallow having a commit depth of <depth> relative to the remote side.
deepen-relative Requests that the semantics of the "deepen" command be changed to indicate that the depth requested is relative to the client's current shallow boundary, instead of relative to the requested commits.
deepen-since <timestamp> Requests that the shallow clone/fetch should be cut at a specific time, instead of depth. Internally it's equivalent to doing "git rev-list --max-age=<timestamp>". Cannot be used with "deepen".
deepen-not <rev> Requests that the shallow clone/fetch should be cut at a specific revision specified by '<rev>', instead of a depth. Internally it's equivalent of doing "git rev-list --not <rev>". Cannot be used with "deepen", but can be used with "deepen-since".
如果宣告了 filter 功能,則以下參數可以包含在客戶端的請求中:
filter <filter-spec> Request that various objects from the packfile be omitted using one of several filtering techniques. These are intended for use with partial clone and partial fetch operations. See `rev-list` for possible "filter-spec" values. When communicating with other processes, senders SHOULD translate scaled integers (e.g. "1k") into a fully-expanded form (e.g. "1024") to aid interoperability with older receivers that may not understand newly-invented scaling suffixes. However, receivers SHOULD accept the following suffixes: 'k', 'm', and 'g' for 1024, 1048576, and 1073741824, respectively.
如果宣告了 ref-in-want 功能,則以下參數可以包含在客戶端的請求中,並且伺服器的回應中可能會加入 wanted-refs 區段,如下所述。
want-ref <ref> Indicates to the server that the client wants to retrieve a particular ref, where <ref> is the full name of a ref on the server. It is a protocol error to send want-ref for the same ref more than once.
如果宣告了 sideband-all 功能,則以下參數可以包含在客戶端的請求中:
sideband-all Instruct the server to send the whole response multiplexed, not just the packfile section. All non-flush and non-delim PKT-LINE in the response (not only in the packfile section) will then start with a byte indicating its sideband (1, 2, or 3), and the server may send "0005\2" (a PKT-LINE of sideband 2 with no payload) as a keepalive packet.
如果宣告了 packfile-uris 功能,則以下參數可以包含在客戶端的請求中,並且伺服器的回應中可能會加入 packfile-uris 區段,如下所述。請注意,最多只能向伺服器發送一個 packfile-uris
行。
packfile-uris <comma-separated-list-of-protocols> Indicates to the server that the client is willing to receive URIs of any of the given protocols in place of objects in the sent packfile. Before performing the connectivity check, the client should download from all given URIs. Currently, the protocols supported are "http" and "https".
如果宣告了 wait-for-done 功能,則以下參數可以包含在客戶端的請求中。
wait-for-done Indicates to the server that it should never send "ready", but should wait for the client to say "done" before sending the packfile.
fetch
的回應會被分成數個區段,並以分隔符數據包 (0001) 分隔,每個區段都以其區段標頭開始。大多數區段僅在傳送 packfile 時才會傳送。
output = acknowledgements flush-pkt | [acknowledgments delim-pkt] [shallow-info delim-pkt] [wanted-refs delim-pkt] [packfile-uris delim-pkt] packfile flush-pkt
acknowledgments = PKT-LINE("acknowledgments" LF) (nak | *ack) (ready) ready = PKT-LINE("ready" LF) nak = PKT-LINE("NAK" LF) ack = PKT-LINE("ACK" SP obj-id LF)
shallow-info = PKT-LINE("shallow-info" LF) *PKT-LINE((shallow | unshallow) LF) shallow = "shallow" SP obj-id unshallow = "unshallow" SP obj-id
wanted-refs = PKT-LINE("wanted-refs" LF) *PKT-LINE(wanted-ref LF) wanted-ref = obj-id SP refname
packfile-uris = PKT-LINE("packfile-uris" LF) *packfile-uri packfile-uri = PKT-LINE(40*(HEXDIGIT) SP *%x20-ff LF)
packfile = PKT-LINE("packfile" LF) *PKT-LINE(%x01-03 *%x00-ff)
acknowledgments section * If the client determines that it is finished with negotiations by sending a "done" line (thus requiring the server to send a packfile), the acknowledgments sections MUST be omitted from the server's response.
-
始終以區段標頭 "acknowledgments" 開始。
-
如果沒有任何以 have 行傳送的物件 ID 是共有的,伺服器將回應 "NAK"。
-
對於所有以 have 行傳送的且為共有的物件 ID,伺服器將回應 "ACK obj-id"。
-
一個回應不能同時包含 "ACK" 行和 "NAK" 行。
-
伺服器將回應 "ready" 行,表示伺服器已找到可接受的共同基礎,並準備好製作和傳送 packfile(這將在同一回應的 packfile 區段中找到)。
-
如果伺服器已找到合適的切入點,並決定傳送 "ready" 行,那麼伺服器可以決定(作為優化)省略其回應期間將傳送的任何 "ACK" 行。這是因為伺服器已確定它計劃傳送給客戶端的物件,並且不需要進一步的協商。
shallow-info section * If the client has requested a shallow fetch/clone, a shallow client requests a fetch or the server is shallow then the server's response may include a shallow-info section. The shallow-info section will be included if (due to one of the above conditions) the server needs to inform the client of any shallow boundaries or adjustments to the clients already existing shallow boundaries.
-
始終以區段標頭 "shallow-info" 開始。
-
如果請求了正深度,伺服器將計算深度不超過所需深度的一組提交。
-
對於每個父級不會在接下來的 packfile 中傳送的提交,伺服器會傳送一個 "shallow obj-id" 行。
-
對於每個客戶端已指示為淺層的提交,但由於其父級已在接下來的 packfile 中傳送而不再是淺層的提交,伺服器會傳送一個 "unshallow obj-id" 行。
-
對於客戶端未在其請求中指示為淺層的任何內容,伺服器絕對不能傳送任何 "unshallow" 行。
wanted-refs section * This section is only included if the client has requested a ref using a 'want-ref' line and if a packfile section is also included in the response.
-
始終以區段標頭 "wanted-refs" 開始。
-
對於每個使用 want-ref 行請求的參考,伺服器將傳送參考列表("<oid> <refname>")。
-
伺服器絕對不能傳送任何未使用 want-ref 行請求的參考。
packfile-uris section * This section is only included if the client sent 'packfile-uris' and the server has at least one such URI to send.
-
始終以區段標頭 "packfile-uris" 開始。
-
對於伺服器傳送的每個 URI,它會傳送 pack 內容的雜湊值(由 git index-pack 輸出)後接 URI。
-
雜湊值是 40 個十六進位字元長。當 Git 升級到新的雜湊演算法時,可能需要更新此值。(它應該與 "pack\t" 或 "keep\t" 之後 index-pack 的輸出相符)。
packfile section * This section is only included if the client has sent 'want' lines in its request and either requested that no more negotiation be done by sending 'done' or if the server has decided it has found a sufficient cut point to produce a packfile.
-
始終以區段標頭 "packfile" 開始。
-
packfile 的傳輸在區段標頭之後立即開始。
-
packfile 的數據傳輸始終使用多路複用,使用與協議版本 1 中的 side-band-64k 功能相同的語義。這表示在 packfile 數據流期間,每個數據包都由前導的 4 位元組 pkt-line 長度(pkt-line 格式的典型長度)、後接 1 位元組的串流程式碼,以及實際的數據組成。
The stream code can be one of: 1 - pack data 2 - progress messages 3 - fatal error message just before stream aborts
server-option
如果宣告,表示請求中可以包含任意數量的伺服器特定選項。這是透過在請求的功能列表區段中將每個選項作為 "server-option=<option>" 功能行傳送來完成的。
提供的選項不得包含 NUL 或 LF 字元。
object-format
伺服器可以使用值 X
(以 object-format=X
形式) 宣告 object-format
功能,以通知客戶端伺服器能夠處理使用雜湊演算法 X 的物件。如果未指定,則假設伺服器僅處理 SHA-1。如果客戶端想要使用 SHA-1 以外的雜湊演算法,則應指定其 object-format 字串。
session-id=<session-id>
伺服器可能會宣告一個會話 ID,該會話 ID 可用於在多個請求中識別此程序。客戶端也可以將自己的會話 ID 回傳給伺服器。
會話 ID 對於給定的程序應是唯一的。它們必須符合數據包行,並且不得包含不可列印或空白字元。目前的實作使用 trace2 會話 ID(詳情請參閱 api-trace2),但這可能會變更,並且會話 ID 的使用者不應依賴此事實。
object-info
object-info
是用於檢索有關一個或多個物件資訊的指令。它的主要目的是允許客戶端根據此資訊做出決策,而無需完整提取物件。物件大小是目前唯一支援的資訊。
一個 object-info
請求接受以下參數:
size Requests size information to be returned for each listed object id.
oid <oid> Indicates to the server an object which the client wants to obtain information for.
object-info
的回應是請求的物件 ID 列表以及相關的請求資訊,每項資訊之間用單個空格分隔。
output = info flush-pkt
info = PKT-LINE(attrs) LF) *PKT-LINE(obj-info LF)
attrs = attr | attrs SP attrs
attr = "size"
obj-info = obj-id SP obj-size
bundle-uri
如果宣告了 bundle-uri 功能,則伺服器支援 'bundle-uri' 指令。
目前,該功能在宣告時沒有任何值(即,不是 "bundle-uri=somevalue"),未來可能會新增一個值以支援命令範圍的擴展。客戶端必須忽略任何未知的功能值,並繼續執行他們支援的 'bundle-uri' 對話。
bundle-uri 指令旨在 fetch
之前發出,以取得 bundle 檔案的 URI(請參閱 git-bundle[1])來「seed」並告知後續的 fetch
指令。
客戶端可以在任何其他有效指令之前或之後發出 bundle-uri
。為了對客戶端有用,預期它會在 ls-refs
之後和 fetch
之前發出,但可以在對話中的任何時間發出。
關於 bundle-uri 的討論
該功能的目的是透過將 git-clone[1] 期間提取非常大的 PACK 的常見情況,更改為較小的增量提取,來優化伺服器在常見情況下的資源消耗。
它還允許伺服器與 uploadpack.packObjectsHook
結合使用,以實現更好的快取(請參閱 git-config[1])。
透過對最近產生的 *.bundle 檔案的提示進行新的複製或提取進行更可預測和常見的協商。伺服器甚至可以在新的推送進入時為 uploadpack.packObjectsHook
預先產生此類協商的結果。
伺服器可以利用這些 bundle 的一種方法是,伺服器會預期新的複製將下載一個已知的 bundle,然後使用該 bundle(或多個 bundle)中找到的 ref 提示來趕上儲存庫的目前狀態。
bundle-uri 的協議
一個 bundle-uri
請求不接受任何參數,並且如上所述,目前沒有宣告功能值。兩者都可能在未來新增。
當客戶端發出 command=bundle-uri
請求時,回應是一組以數據包行形式提供的鍵值對,值為 <key>=<value>
。每個 <key>
都應被解釋為來自 bundle.*
命名空間的配置鍵,以建構 bundle 列表。這些鍵按 bundle.<id>.
小節分組,其中每個對應於給定 <id>
的鍵都會為該 <id>
定義的 bundle 提供屬性。 有關這些鍵的具體詳細資訊以及 Git 客戶端將如何解釋其值的資訊,請參閱 git-config[1]。
客戶端必須根據上述格式剖析該行,不符合該格式的行應被丟棄。在這種情況下,可能會向用戶發出警告。
bundle-uri 客戶端和伺服器預期
- URI 內容
-
宣告的 URI 中的內容必須是兩種類型之一。
宣告的 URI 可能包含一個
git bundle verify
會接受的 bundle 檔案。也就是說,它們必須包含一個或多個供客戶端使用的參考提示,必須使用標準的 "-" 字首指示先決條件(如果有),並且必須指示它們的 "object-format"(如果適用)。宣告的 URI 也可能包含一個
git config --list
會接受的純文字檔案(使用--file
選項)。此列表中的鍵值對位於bundle.*
命名空間中(請參閱 git-config[1])。 - bundle-uri 客戶端錯誤恢復
-
客戶端必須首先在錯誤時優雅地降級,無論該錯誤是因為 bundle URI 中的錯誤缺失/數據、因為該客戶端太笨而無法完全理解和剖析 bundle 標頭及其先決條件關係,還是其他原因。
伺服器運營商應該對開啟 "bundle-uri" 感到自信,並且不用擔心,例如,如果他們的 CDN 停機,複製或提取會遇到嚴重的故障。即使伺服器 bundle 不完整,或者存在某些問題,客戶端仍然應該會獲得一個可以正常運作的儲存庫,就像它選擇不使用此協議擴展一樣。
所有關於客戶端和伺服器互動的後續討論都必須記住這一點。
- bundle-uri 從伺服器到客戶端
-
傳回的 bundle URI 的順序並不重要。客戶端必須剖析其標頭以發現它們包含的 OID 和先決條件。客戶端必須將 bundle 本身的內容及其標頭視為最終的事實來源。
伺服器甚至可能會傳回與正在複製的儲存庫沒有任何直接關係的 bundle(無論是偶然還是有意的「聰明」配置),並期望客戶端從 bundle 中整理出他們想要的任何資料(如果有)。
- bundle-uri 從客戶端到伺服器
-
客戶端應在任何後續的
fetch
請求中,將在 bundle 標頭中找到的參考提示作為 have 行提供。如果由於某種原因,這樣做被認為更糟糕,例如,如果無法下載 bundle、不喜歡找到的提示等等,則客戶端也可能會完全忽略 bundle。 - 當宣告的 BUNDLE 不需要進一步協商時
-
若在發出
bundle-uri
和ls-refs
指令並取得 bundle 的標頭後,客戶端發現其想要的 ref tips 可以完全從已宣告的 bundle 中取得,則客戶端可以斷開與 Git 伺服器的連線。這種clone或fetch的結果,應該與未使用 bundle-uri 達到的狀態沒有區別。 - 客戶端提前斷線與錯誤恢復
-
客戶端在仍在下載 bundle 時(已串流並解析其標頭)可以執行提前斷線。在這種情況下,客戶端必須優雅地從與完成 bundle 的下載和驗證相關的任何錯誤中恢復。
也就是說,客戶端可能需要重新連線並發出 fetch 命令,並可能退回到完全不使用 bundle-uri 的情況。
之所以將此行為指定為「可以」(MAY)而不是「應該」(SHOULD),是因為假設宣告 bundle URI 的伺服器,更有可能是在提供一個相對較大的儲存庫,並且指向的 URI 很有可能是正常工作的。例如,客戶端可以查看 bundle 的有效負載大小作為一個啟發式方法,來判斷是否值得提前斷線,如果需要退回到完整的「fetch」對話。
- 當宣告的 Bundle 需要進一步協商時
-
即使客戶端仍在下載這些 bundle,也應該使用在宣告的 bundle 中找到的 OID tips,透過 "fetch" 命令開始與伺服器協商 PACK。
這允許從任何互動式伺服器對話中進行積極的提前斷線。客戶端盲目信任宣告的 OID tips 是相關的,並將它們作為 have 行發出,然後透過 want 行請求它想要的任何 tips(通常來自 "ls-refs" 宣告)。然後,伺服器將計算一個(希望很小的)PACK,其中包含 bundle 的 tips 和請求的數據之間的預期差異。
客戶端唯一需要保持活動的連線是對同時下載的靜態 bundle,當這些 bundle 和增量 PACK 被擷取時,它們應該被解壓縮和驗證。此時的任何錯誤都應優雅地恢復,如上所述。
bundle-uri 協定功能
客戶端從伺服器提供的 <key>=<value>
配對建立 bundle 列表。這些配對是 bundle.*
命名空間的一部分,如 git-config[1] 中所述。在本節中,我們將討論其中一些鍵,並描述客戶端將根據此資訊執行的動作。
特別是,bundle.version
鍵指定一個整數值。目前唯一接受的值是 1
,但如果客戶端在此處看到意外的值,則客戶端必須忽略 bundle 列表。
只要理解 bundle.version
,客戶端可以忽略所有其他未知的鍵。伺服器將保證與舊客戶端的相容性,儘管較新的客戶端可能更能夠使用額外的鍵來最小化下載。
任何與 URI 前的鍵值不相容的增加,都將透過新的 bundle.version
值或 bundle-uri 功能宣告本身的值,和/或透過未來新的 bundle-uri
請求參數來保護。
一些目前尚未實作,但未來可以實作的鍵值對範例包括
-
新增一個 "hash=<val>" 或 "size=<bytes>",以宣告 bundle 檔案的預期雜湊或大小。
-
宣告一個或多個 bundle 檔案是相同的(例如,讓客戶端輪流或以其他方式選擇 N 個可能的檔案之一)。
-
一個 "oid=<OID>" 捷徑和 "prerequisite=<OID>" 捷徑。用於表達具有一個 tip 且沒有先決條件,或一個 tip 和一個先決條件的 bundle 的常見情況。
這將允許優化伺服器的常見情況,這些伺服器希望提供一個僅包含其 "main" 分支和/或其增量更新的「大型 bundle」。
接收到此類回應的客戶端可以假設它們可以跳過從指示 URI 處檢索 bundle 的標頭,從而為它們自己和伺服器節省檢查該 bundle 或多個 bundle 標頭所需的請求。
GIT
屬於 git[1] 套件的一部分