设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
修补
调试
电子邮件
外部系统
服务器管理
指南
管理
底层命令
- 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 远程助手可以充当代理
在协议 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:// 传输时,客户机将发出 "智能" info/refs 请求,如 gitprotocol-http[5] 中所述,并通过在 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 的空请求,以表明不再发出请求。
功能
功能有两种类型:普通功能,用于传达信息或更改请求的行为;命令,是客户机想要执行的核心操作(fetch、push 等)。
协议版本 2 默认情况下是无状态的。这意味着所有命令都必须只持续一个回合,并且从服务器端来看是无状态的,除非客户机请求一个表示状态应该由服务器维护的功能。客户机在正常运行时,必须不要求服务器端进行状态管理。这允许服务器端进行简单的轮询负载均衡,而无需担心状态管理。
代理
服务器可以通过使用值 X
(以 agent=X
的形式)宣传 agent
功能,以通知客户机服务器正在运行版本 X
。客户机可以选择通过在其对服务器的请求中包含值 Y
的 agent
功能(以 agent=Y
的形式)来发送自己的代理字符串(但如果服务器没有宣传代理功能,则必须不要这样做)。X
和 Y
字符串可以包含任何可打印的 ASCII 字符,除了空格(即字节范围 32 < x < 127),并且通常采用 "package/version" 的形式(例如,"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 的修改版本,其中引用广告被剥离(因为 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”,这些对象 ID 是相同的。
-
响应不能同时包含“ACK”行和“NAK”行。
-
服务器将响应“ready”行,表示服务器已找到可接受的公共基准,并已准备好制作和发送 packfile(该 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”。
-
对于每个客户端已指示为浅层但不再是浅层的提交,服务器将发送一行“unshallow obj-id”(因为其父节点将在后续 packfile 中发送)。
-
服务器绝不能发送任何“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
如果被广告,表示可以在请求中包含任意数量的服务器特定选项。这是通过在请求的 capability-list 部分中将每个选项作为“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 应该对给定进程是唯一的。它们必须适合在一个 packet-line 内,并且不得包含不可打印字符或空格字符。当前实现使用 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
之前发出,以获取捆绑文件(请参阅 git-bundle[1])的 URI,以“播种”并告知随后的fetch
命令。
客户端可以在任何其他有效命令之前或之后发出bundle-uri
。为了对客户端有用,预计它将在ls-refs
之后和fetch
之前发出,但可以在对话框中的任何时间发出。
关于 bundle-uri 的讨论
该功能的目的是在常见情况下优化服务器资源消耗,方法是将常见的在 git-clone[1] 期间获取非常大的 PACK 的情况更改为更小的增量获取。
它还允许服务器与uploadpack.packObjectsHook
(请参阅 git-config[1])结合使用,实现更好的缓存。
通过让新的克隆或获取与最近生成的 *.bundle 文件的提示进行更可预测和更常见的协商。服务器甚至可以在新的推送进来时预先生成此类协商的结果,以用于uploadpack.packObjectsHook
。
服务器可以利用这些捆绑包的一种方法是,服务器会预料到新的克隆将下载已知的捆绑包,然后使用在该捆绑包(或捆绑包)中找到的引用提示追赶到存储库的当前状态。
bundle-uri 的协议
bundle-uri
请求不接受任何参数,并且如上所述,目前没有广告任何功能值。两者都可能在将来添加。
当客户端发出command=bundle-uri
请求时,响应是作为数据包行提供的键值对列表,其值为<key>=<value>
。每个<key>
应该被解释为来自bundle.*
命名空间的配置键,用于构建捆绑包列表。这些键按bundle.<id>.
子部分进行分组,其中与给定<id>
相对应的每个键都为由该<id>
定义的捆绑包贡献属性。请参阅 git-config[1] 以了解这些键的具体细节以及 Git 客户端如何解释它们的值。
客户端必须根据上述格式解析该行,不符合格式的行应该被丢弃。在这种情况下,用户可能会收到警告。
bundle-uri 客户端和服务器期望
- URI 内容
-
广告的 URI 中的内容必须是以下两种类型之一。
广告的 URI 可能包含一个
git bundle verify
会接受的捆绑包文件。即它们必须包含一个或多个用于客户端的引用提示,必须用标准的“-”前缀指示先决条件(如果有),并且必须指示其“object-format”(如果适用)。广告的 URI 也可以包含一个
git config --list
会接受的纯文本文件(使用--file
选项)。此列表中的键值对位于bundle.*
命名空间中(请参阅 git-config[1])。 - bundle-uri 客户端错误恢复
-
客户端必须最重要的是在发生错误时优雅地降级,无论是由于捆绑包 URI 中的错误数据或缺失数据造成的,还是因为该客户端过于愚蠢而无法理解和完全解析出捆绑包标题及其先决条件关系,或者其他原因。
服务器操作员应该对启用“bundle-uri”充满信心,并且不要担心例如他们的 CDN 出现故障会导致克隆或获取出现严重的故障。即使服务器捆绑包不完整或以某种方式损坏,客户端也应该最终得到一个正常工作的存储库,就像它选择不使用此协议扩展一样。
所有关于客户端和服务器交互的后续讨论必须牢记这一点。
- bundle-uri 服务器到客户端
-
返回的捆绑包 URI 的顺序无关紧要。客户端必须解析其标题以发现其包含的 OID 和先决条件。客户端必须将捆绑包本身及其标题的内容视为最终的真实来源。
服务器甚至可以返回与正在克隆的存储库没有直接关系的捆绑包(无论是由于意外还是故意“巧妙”配置),并希望客户端从捆绑包中筛选出他们想要的数据(如果有)。
- bundle-uri 客户端到服务器
-
客户端应该在任何后续的
fetch
请求中以have 行的形式提供在捆绑包标题中找到的引用提示。如果出于某种原因,这样做被认为更糟糕,客户端也可以完全忽略捆绑包,例如,如果无法下载捆绑包,它不喜欢它找到的提示等。 - 当广告的捆绑包不需要进一步协商时
-
如果在发出
bundle-uri
和ls-refs
之后,并获取到捆绑包的标题后,客户端发现它想要的引用提示可以完全从广告的捆绑包中检索到,客户端可以断开与 Git 服务器的连接。此类克隆或获取的结果应该与不使用 bundle-uri 时获得的状态相同。 - 客户端提前断开连接和错误恢复
-
客户端可以在仍然下载捆绑包时执行提前断开连接(已经流式传输并解析了其标题)。在这种情况下,客户端必须优雅地从与完成捆绑包的下载和验证相关的任何错误中恢复。
也就是说,客户端可能需要重新连接并发出一个fetch 命令,并且可能完全放弃使用bundle-uri。
这种“可以”行为被指定为这样(而不是“应该”),假设广告捆绑包 URI 的服务器更有可能为相对较大的存储库提供服务,并指向更有可能处于工作状态的 URI。客户端可以例如查看捆绑包的有效载荷大小作为启发式方法,以查看提前断开连接是否值得,如果需要回退到完整的“fetch”对话框。
- 当广告的捆绑包需要进一步协商时
-
客户端应该通过“fetch”命令使用在广告的捆绑包中找到的 OID 提示开始与服务器协商 PACK,即使它仍然在下载这些捆绑包。
这允许从任何交互式服务器对话框中积极地早期断开连接。客户端盲目信任广告的 OID 提示是相关的,并将它们作为have 行发出,然后它通过want 行请求它想要的任何提示(通常来自“ls-refs”广告)。然后,服务器将计算一个(希望很小)PACK,其中包含来自捆绑包(s)的提示与请求的数据之间的预期差异。
客户端只需要保持与并发下载的静态捆绑包(s)的连接,当这些捆绑包和增量 PACK 被检索到时,它们应该被膨胀和验证。此时发生的任何错误都应该被优雅地恢复,见上文。
bundle-uri 协议特性
客户端从服务器提供的<key>=<value>
对构建一个捆绑包列表。这些对是bundle.*
命名空间的一部分,如git-config[1] 中所述。在本节中,我们将讨论其中的一些键,并描述客户端对这些信息的响应所采取的行动。
特别是,bundle.version
键指定一个整数值。目前唯一接受的值是1
,但如果客户端在此处看到一个意外的值,则客户端必须忽略捆绑包列表。
只要bundle.version
被理解,客户端可以忽略所有其他未知的键。服务器将保证与旧客户端的兼容性,尽管新客户端可能能够更好地利用额外的键来最大限度地减少下载。
任何向后不兼容的 URI 前键值添加将通过新的bundle.version
值或bundle-uri 能力广告本身中的值,以及/或通过新的未来bundle-uri
请求参数来保护。
一些目前未实现但将来可能实现的示例键值对包括
-
添加一个 "hash=<val>" 或 "size=<bytes>" 来广告捆绑包文件的预期哈希或大小。
-
广告一个或多个捆绑包文件是相同的(例如,让客户端循环或以其他方式选择 N 个可能的 文件中的一个)。
-
一个 "oid=<OID>" 快捷方式和 "prerequisite=<OID>" 快捷方式。用于表达一个带有单个提示且没有先决条件的捆绑包,或一个带有单个提示和单个先决条件的捆绑包的常见情况。
这将允许优化服务器希望提供一个只包含其 “主” 分支的 “大捆绑包”,以及/或其增量更新的常见情况。
接收此类响应的客户端可以假设他们可以跳过检索来自指示 URI 的捆绑包的标头,从而节省自身和服务器(s)检查该捆绑包或捆绑包标头所需的请求(s)。
GIT
是 git[1] 套件的一部分