1GITPROTOCOL-V2(5) Git Manual GITPROTOCOL-V2(5)
2
6 gitprotocol-v2 - Git Wire Protocol, Version 2
7
9 <over-the-wire-protocol>
10
12 This document presents a specification for a version 2 of Git’s wire
13 protocol. Protocol v2 will improve upon v1 in the following ways:
14 • Instead of multiple service names, multiple commands will be
16 supported by a single service
17 • Easily extendable as capabilities are moved into their own section
19 of the protocol, no longer being hidden behind a NUL byte and
20 limited by the size of a pkt-line
21 • Separate out other information hidden behind NUL bytes (e.g. agent
23 string as a capability and symrefs can be requested using ls-refs)
24 • Reference advertisement will be omitted unless explicitly requested
26 • ls-refs command to explicitly request some refs
28 • Designed with http and stateless-rpc in mind. With clear flush
30 semantics the http remote helper can simply act as a proxy
31 In protocol v2 communication is command oriented. When first contacting
33 a server a list of capabilities will be advertised. Some of these
34 capabilities will be commands which a client can request be executed.
35 Once a command has completed, a client can reuse the connection and
36 request that other commands be executed.
37
39 All communication is done using packet-line framing, just as in v1. See
40 gitprotocol-pack(5) and gitprotocol-common(5) for more information.
41 In protocol v2 these special packets will have the following semantics:
43 • 0000 Flush Packet (flush-pkt) - indicates the end of a message
45 • 0001 Delimiter Packet (delim-pkt) - separates sections of a message
47 • 0002 Response End Packet (response-end-pkt) - indicates the end of
49 a response for stateless connections
50
52 In general a client can request to speak protocol v2 by sending
53 version=2 through the respective side-channel for the transport being
54 used which inevitably sets GIT_PROTOCOL. More information can be found
55 in gitprotocol-pack(5) and gitprotocol-http(5), as well as the
56 GIT_PROTOCOL definition in git.txt. In all cases the response from the
57 server is the capability advertisement.
58 Git Transport
60 When using the git:// transport, you can request to use protocol v2 by
61 sending "version=2" as an extra parameter:
62 003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0
64 SSH and File Transport
66 When using either the ssh:// or file:// transport, the GIT_PROTOCOL
67 environment variable must be set explicitly to include "version=2". The
68 server may need to be configured to allow this environment variable to
69 pass.
70 HTTP Transport
72 When using the http:// or https:// transport a client makes a "smart"
73 info/refs request as described in gitprotocol-http(5) and requests that
74 v2 be used by supplying "version=2" in the Git-Protocol header.
75 C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
77 C: Git-Protocol: version=2
78 A v2 server would reply:
80 S: 200 OK
82 S: <Some headers>
83 S: ...
84 S:
85 S: 000eversion 2\n
86 S: <capability-advertisement>
87 Subsequent requests are then made directly to the service
89 $GIT_URL/git-upload-pack. (This works the same for git-receive-pack).
90 Uses the --http-backend-info-refs option to git-upload-pack(1).
92 The server may need to be configured to pass this header’s contents via
94 the GIT_PROTOCOL variable. See the discussion in git-http-backend.txt.
95
97 A server which decides to communicate (based on a request from a
98 client) using protocol version 2, notifies the client by sending a
99 version string in its initial response followed by an advertisement of
100 its capabilities. Each capability is a key with an optional value.
101 Clients must ignore all unknown keys. Semantics of unknown values are
102 left to the definition of each key. Some capabilities will describe
103 commands which can be requested to be executed by the client.
104 capability-advertisement = protocol-version
106 capability-list
107 flush-pkt
108 protocol-version = PKT-LINE("version 2" LF)
110 capability-list = *capability
111 capability = PKT-LINE(key[=value] LF)
112 key = 1*(ALPHA | DIGIT | "-_")
114 value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")
115
117 After receiving the capability advertisement, a client can then issue a
118 request to select the command it wants with any particular capabilities
119 or arguments. There is then an optional section where the client can
120 provide any command specific parameters or queries. Only a single
121 command can be requested at a time.
122 request = empty-request | command-request
124 empty-request = flush-pkt
125 command-request = command
126 capability-list
127 delim-pkt
128 command-args
129 flush-pkt
130 command = PKT-LINE("command=" key LF)
131 command-args = *command-specific-arg
132 command-specific-args are packet line framed arguments defined by
134 each individual command.
135 The server will then check to ensure that the client’s request is
137 comprised of a valid command as well as valid capabilities which were
138 advertised. If the request is valid the server will then execute the
139 command. A server MUST wait till it has received the client’s entire
140 request before issuing a response. The format of the response is
141 determined by the command being executed, but in all cases a flush-pkt
142 indicates the end of the response.
143 When a command has finished, and the client has received the entire
145 response from the server, a client can either request that another
146 command be executed or can terminate the connection. A client may
147 optionally send an empty request consisting of just a flush-pkt to
148 indicate that no more requests will be made.
149
151 There are two different types of capabilities: normal capabilities,
152 which can be used to convey information or alter the behavior of a
153 request, and commands, which are the core actions that a client wants
154 to perform (fetch, push, etc).
155 Protocol version 2 is stateless by default. This means that all
157 commands must only last a single round and be stateless from the
158 perspective of the server side, unless the client has requested a
159 capability indicating that state should be maintained by the server.
160 Clients MUST NOT require state management on the server side in order
161 to function correctly. This permits simple round-robin load-balancing
162 on the server side, without needing to worry about state management.
163 agent
165 The server can advertise the agent capability with a value X (in the
166 form agent=X) to notify the client that the server is running version
167 X. The client may optionally send its own agent string by including the
168 agent capability with a value Y (in the form agent=Y) in its request to
169 the server (but it MUST NOT do so if the server did not advertise the
170 agent capability). The X and Y strings may contain any printable ASCII
171 characters except space (i.e., the byte range 32 < x < 127), and are
172 typically of the form "package/version" (e.g., "git/1.8.3.1"). The
173 agent strings are purely informative for statistics and debugging
174 purposes, and MUST NOT be used to programmatically assume the presence
175 or absence of particular features.
176 ls-refs
178 ls-refs is the command used to request a reference advertisement in v2.
179 Unlike the current reference advertisement, ls-refs takes in arguments
180 which can be used to limit the refs sent from the server.
181 Additional features not supported in the base command will be
183 advertised as the value of the command in the capability advertisement
184 in the form of a space separated list of features: "<command>=<feature
185 1> <feature 2>"
186 ls-refs takes in the following arguments:
188 symrefs
190 In addition to the object pointed by it, show the underlying ref
191 pointed by it when showing a symbolic ref.
192 peel
193 Show peeled tags.
194 ref-prefix <prefix>
195 When specified, only references having a prefix matching one of
196 the provided prefixes are displayed. Multiple instances may be
197 given, in which case references matching any prefix will be
198 shown. Note that this is purely for optimization; a server MAY
199 show refs not matching the prefix if it chooses, and clients
200 should filter the result themselves.
201 If the unborn feature is advertised the following argument can be
203 included in the client’s request.
204 unborn
206 The server will send information about HEAD even if it is a symref
207 pointing to an unborn branch in the form "unborn HEAD
208 symref-target:<target>".
209 The output of ls-refs is as follows:
211 output = *ref
213 flush-pkt
214 obj-id-or-unborn = (obj-id | "unborn")
215 ref = PKT-LINE(obj-id-or-unborn SP refname *(SP ref-attribute) LF)
216 ref-attribute = (symref | peeled)
217 symref = "symref-target:" symref-target
218 peeled = "peeled:" obj-id
219 fetch
221 fetch is the command used to fetch a packfile in v2. It can be looked
222 at as a modified version of the v1 fetch where the ref-advertisement is
223 stripped out (since the ls-refs command fills that role) and the
224 message format is tweaked to eliminate redundancies and permit easy
225 addition of future extensions.
226 Additional features not supported in the base command will be
228 advertised as the value of the command in the capability advertisement
229 in the form of a space separated list of features: "<command>=<feature
230 1> <feature 2>"
231 A fetch request can take the following arguments:
233 want <oid>
235 Indicates to the server an object which the client wants to
236 retrieve. Wants can be anything and are not limited to
237 advertised objects.
238 have <oid>
240 Indicates to the server an object which the client has locally.
241 This allows the server to make a packfile which only contains
242 the objects that the client needs. Multiple 'have' lines can be
243 supplied.
244 done
246 Indicates to the server that negotiation should terminate (or
247 not even begin if performing a clone) and that the server should
248 use the information supplied in the request to construct the
249 packfile.
250 thin-pack
252 Request that a thin pack be sent, which is a pack with deltas
253 which reference base objects not contained within the pack (but
254 are known to exist at the receiving end). This can reduce the
255 network traffic significantly, but it requires the receiving end
256 to know how to "thicken" these packs by adding the missing bases
257 to the pack.
258 no-progress
260 Request that progress information that would normally be sent on
261 side-band channel 2, during the packfile transfer, should not be
262 sent. However, the side-band channel 3 is still used for error
263 responses.
264 include-tag
266 Request that annotated tags should be sent if the objects they
267 point to are being sent.
268 ofs-delta
270 Indicate that the client understands PACKv2 with delta referring
271 to its base by position in pack rather than by an oid. That is,
272 they can read OBJ_OFS_DELTA (aka type 6) in a packfile.
273 If the shallow feature is advertised the following arguments can be
275 included in the clients request as well as the potential addition of
276 the shallow-info section in the server’s response as explained below.
277 shallow <oid>
279 A client must notify the server of all commits for which it only
280 has shallow copies (meaning that it doesn't have the parents of
281 a commit) by supplying a 'shallow <oid>' line for each such
282 object so that the server is aware of the limitations of the
283 client's history. This is so that the server is aware that the
284 client may not have all objects reachable from such commits.
285 deepen <depth>
287 Requests that the fetch/clone should be shallow having a commit
288 depth of <depth> relative to the remote side.
289 deepen-relative
291 Requests that the semantics of the "deepen" command be changed
292 to indicate that the depth requested is relative to the client's
293 current shallow boundary, instead of relative to the requested
294 commits.
295 deepen-since <timestamp>
297 Requests that the shallow clone/fetch should be cut at a
298 specific time, instead of depth. Internally it's equivalent to
299 doing "git rev-list --max-age=<timestamp>". Cannot be used with
300 "deepen".
301 deepen-not <rev>
303 Requests that the shallow clone/fetch should be cut at a
304 specific revision specified by '<rev>', instead of a depth.
305 Internally it's equivalent of doing "git rev-list --not <rev>".
306 Cannot be used with "deepen", but can be used with
307 "deepen-since".
308 If the filter feature is advertised, the following argument can be
310 included in the client’s request:
311 filter <filter-spec>
313 Request that various objects from the packfile be omitted
314 using one of several filtering techniques. These are intended
315 for use with partial clone and partial fetch operations. See
316 `rev-list` for possible "filter-spec" values. When communicating
317 with other processes, senders SHOULD translate scaled integers
318 (e.g. "1k") into a fully-expanded form (e.g. "1024") to aid
319 interoperability with older receivers that may not understand
320 newly-invented scaling suffixes. However, receivers SHOULD
321 accept the following suffixes: 'k', 'm', and 'g' for 1024,
322 1048576, and 1073741824, respectively.
323 If the ref-in-want feature is advertised, the following argument can be
325 included in the client’s request as well as the potential addition of
326 the wanted-refs section in the server’s response as explained below.
327 want-ref <ref>
329 Indicates to the server that the client wants to retrieve a
330 particular ref, where <ref> is the full name of a ref on the
331 server.
332 If the sideband-all feature is advertised, the following argument can
334 be included in the client’s request:
335 sideband-all
337 Instruct the server to send the whole response multiplexed, not just
338 the packfile section. All non-flush and non-delim PKT-LINE in the
339 response (not only in the packfile section) will then start with a byte
340 indicating its sideband (1, 2, or 3), and the server may send "0005\2"
341 (a PKT-LINE of sideband 2 with no payload) as a keepalive packet.
342 If the packfile-uris feature is advertised, the following argument can
344 be included in the client’s request as well as the potential addition
345 of the packfile-uris section in the server’s response as explained
346 below.
347 packfile-uris <comma-separated list of protocols>
349 Indicates to the server that the client is willing to receive
350 URIs of any of the given protocols in place of objects in the
351 sent packfile. Before performing the connectivity check, the
352 client should download from all given URIs. Currently, the
353 protocols supported are "http" and "https".
354 If the wait-for-done feature is advertised, the following argument can
356 be included in the client’s request.
357 wait-for-done
359 Indicates to the server that it should never send "ready", but
360 should wait for the client to say "done" before sending the
361 packfile.
362 The response of fetch is broken into a number of sections separated by
364 delimiter packets (0001), with each section beginning with its section
365 header. Most sections are sent only when the packfile is sent.
366 output = acknowledgements flush-pkt |
368 [acknowledgments delim-pkt] [shallow-info delim-pkt]
369 [wanted-refs delim-pkt] [packfile-uris delim-pkt]
370 packfile flush-pkt
371 acknowledgments = PKT-LINE("acknowledgments" LF)
373 (nak | *ack)
374 (ready)
375 ready = PKT-LINE("ready" LF)
376 nak = PKT-LINE("NAK" LF)
377 ack = PKT-LINE("ACK" SP obj-id LF)
378 shallow-info = PKT-LINE("shallow-info" LF)
380 *PKT-LINE((shallow | unshallow) LF)
381 shallow = "shallow" SP obj-id
382 unshallow = "unshallow" SP obj-id
383 wanted-refs = PKT-LINE("wanted-refs" LF)
385 *PKT-LINE(wanted-ref LF)
386 wanted-ref = obj-id SP refname
387 packfile-uris = PKT-LINE("packfile-uris" LF) *packfile-uri
389 packfile-uri = PKT-LINE(40*(HEXDIGIT) SP *%x20-ff LF)
390 packfile = PKT-LINE("packfile" LF)
392 *PKT-LINE(%x01-03 *%x00-ff)
393 acknowledgments section
395 * If the client determines that it is finished with negotiations by
396 sending a "done" line (thus requiring the server to send a packfile),
397 the acknowledgments sections MUST be omitted from the server's
398 response.
399 • Always begins with the section header "acknowledgments"
401 • The server will respond with "NAK" if none of the object ids sent
403 as have lines were common.
404 • The server will respond with "ACK obj-id" for all of the object ids
406 sent as have lines which are common.
407 • A response cannot have both "ACK" lines as well as a "NAK" line.
409 • The server will respond with a "ready" line indicating that the
411 server has found an acceptable common base and is ready to make and
412 send a packfile (which will be found in the packfile section of the
413 same response)
414 • If the server has found a suitable cut point and has decided to
416 send a "ready" line, then the server can decide to (as an
417 optimization) omit any "ACK" lines it would have sent during its
418 response. This is because the server will have already determined
419 the objects it plans to send to the client and no further
420 negotiation is needed.
421 shallow-info section
423 * If the client has requested a shallow fetch/clone, a shallow
424 client requests a fetch or the server is shallow then the
425 server's response may include a shallow-info section. The
426 shallow-info section will be included if (due to one of the
427 above conditions) the server needs to inform the client of any
428 shallow boundaries or adjustments to the clients already
429 existing shallow boundaries.
430 • Always begins with the section header "shallow-info"
432 • If a positive depth is requested, the server will compute the set
434 of commits which are no deeper than the desired depth.
435 • The server sends a "shallow obj-id" line for each commit whose
437 parents will not be sent in the following packfile.
438 • The server sends an "unshallow obj-id" line for each commit which
440 the client has indicated is shallow, but is no longer shallow as a
441 result of the fetch (due to its parents being sent in the following
442 packfile).
443 • The server MUST NOT send any "unshallow" lines for anything which
445 the client has not indicated was shallow as a part of its request.
446 wanted-refs section
448 * This section is only included if the client has requested a
449 ref using a 'want-ref' line and if a packfile section is also
450 included in the response.
451 • Always begins with the section header "wanted-refs".
453 • The server will send a ref listing ("<oid> <refname>") for each
455 reference requested using want-ref lines.
456 • The server MUST NOT send any refs which were not requested using
458 want-ref lines.
459 packfile-uris section
461 * This section is only included if the client sent
462 'packfile-uris' and the server has at least one such URI to
463 send.
464 • Always begins with the section header "packfile-uris".
466 • For each URI the server sends, it sends a hash of the pack’s
468 contents (as output by git index-pack) followed by the URI.
469 • The hashes are 40 hex characters long. When Git upgrades to a new
471 hash algorithm, this might need to be updated. (It should match
472 whatever index-pack outputs after "pack\t" or "keep\t".
473 packfile section
475 * This section is only included if the client has sent 'want'
476 lines in its request and either requested that no more
477 negotiation be done by sending 'done' or if the server has
478 decided it has found a sufficient cut point to produce a
479 packfile.
480 • Always begins with the section header "packfile"
482 • The transmission of the packfile begins immediately after the
484 section header
485 • The data transfer of the packfile is always multiplexed, using the
487 same semantics of the side-band-64k capability from protocol
488 version 1. This means that each packet, during the packfile data
489 stream, is made up of a leading 4-byte pkt-line length (typical of
490 the pkt-line format), followed by a 1-byte stream code, followed by
491 the actual data.
492 The stream code can be one of:
494 1 - pack data
495 2 - progress messages
496 3 - fatal error message just before stream aborts
497 server-option
499 If advertised, indicates that any number of server specific options can
500 be included in a request. This is done by sending each option as a
501 "server-option=<option>" capability line in the capability-list section
502 of a request.
503 The provided options must not contain a NUL or LF character.
505 object-format
507 The server can advertise the object-format capability with a value X
508 (in the form object-format=X) to notify the client that the server is
509 able to deal with objects using hash algorithm X. If not specified, the
510 server is assumed to only handle SHA-1. If the client would like to use
511 a hash algorithm other than SHA-1, it should specify its object-format
512 string.
513 session-id=<session id>
515 The server may advertise a session ID that can be used to identify this
516 process across multiple requests. The client may advertise its own
517 session ID back to the server as well.
518 Session IDs should be unique to a given process. They must fit within a
520 packet-line, and must not contain non-printable or whitespace
521 characters. The current implementation uses trace2 session IDs (see
522 api-trace2[1] for details), but this may change and users of the
523 session ID should not rely on this fact.
524 object-info
526 object-info is the command to retrieve information about one or more
527 objects. Its main purpose is to allow a client to make decisions based
528 on this information without having to fully fetch objects. Object size
529 is the only information that is currently supported.
530 An object-info request takes the following arguments:
532 size
534 Requests size information to be returned for each listed object id.
535 oid <oid>
537 Indicates to the server an object which the client wants to obtain
538 information for.
539 The response of object-info is a list of the requested object ids and
541 associated requested information, each separated by a single space.
542 output = info flush-pkt
544 info = PKT-LINE(attrs) LF)
546 *PKT-LINE(obj-info LF)
547 attrs = attr | attrs SP attrs
549 attr = "size"
551 obj-info = obj-id SP obj-size
553 bundle-uri
555 If the bundle-uri capability is advertised, the server supports the
556 “bundle-uri” command.
557 The capability is currently advertised with no value (i.e. not
559 "bundle-uri=somevalue"), a value may be added in the future for
560 supporting command-wide extensions. Clients MUST ignore any unknown
561 capability values and proceed with the 'bundle-uri` dialog they
562 support.
563 The bundle-uri command is intended to be issued before fetch to get
565 URIs to bundle files (see git-bundle(1)) to "seed" and inform the
566 subsequent fetch command.
567 The client CAN issue bundle-uri before or after any other valid
569 command. To be useful to clients it’s expected that it’ll be issued
570 after an ls-refs and before fetch, but CAN be issued at any time in the
571 dialog.
572 DISCUSSION of bundle-uri
574 The intent of the feature is optimize for server resource
575 consumption in the common case by changing the common case of
576 fetching a very large PACK during git-clone(1) into a smaller
577 incremental fetch.
578 It also allows servers to achieve better caching in combination
580 with an uploadpack.packObjectsHook (see git-config(1)).
581 By having new clones or fetches be a more predictable and common
583 negotiation against the tips of recently produces *.bundle file(s).
584 Servers might even pre-generate the results of such negotiations
585 for the uploadpack.packObjectsHook as new pushes come in.
586 One way that servers could take advantage of these bundles is that
588 the server would anticipate that fresh clones will download a known
589 bundle, followed by catching up to the current state of the
590 repository using ref tips found in that bundle (or bundles).
591 PROTOCOL for bundle-uri
593 A bundle-uri request takes no arguments, and as noted above does
594 not currently advertise a capability value. Both may be added in
595 the future.
596 When the client issues a command=bundle-uri request, the response
598 is a list of key-value pairs provided as packet lines with value
599 <key>=<value>. Each <key> should be interpreted as a config key
600 from the bundle.* namespace to construct a list of bundles. These
601 keys are grouped by a bundle.<id>. subsection, where each key
602 corresponding to a given <id> contributes attributes to the bundle
603 defined by that <id>. See git-config(1) for the specific details of
604 these keys and how the Git client will interpret their values.
605 Clients MUST parse the line according to the above format, lines
607 that do not conform to the format SHOULD be discarded. The user MAY
608 be warned in such a case.
609 bundle-uri CLIENT AND SERVER EXPECTATIONS
611 URI CONTENTS
612 The content at the advertised URIs MUST be one of two types.
613 The advertised URI may contain a bundle file that git bundle
615 verify would accept. I.e. they MUST contain one or more
616 reference tips for use by the client, MUST indicate
617 prerequisites (in any) with standard "-" prefixes, and MUST
618 indicate their "object-format", if applicable.
619 The advertised URI may alternatively contain a plaintext file
621 that git config --list would accept (with the --file option).
622 The key-value pairs in this list are in the bundle.* namespace
623 (see git-config(1)).
624 bundle-uri CLIENT ERROR RECOVERY
626 A client MUST above all gracefully degrade on errors, whether
627 that error is because of bad missing/data in the bundle URI(s),
628 because that client is too dumb to e.g. understand and fully
629 parse out bundle headers and their prerequisite relationships,
630 or something else.
631 Server operators should feel confident in turning on
633 "bundle-uri" and not worry if e.g. their CDN goes down that
634 clones or fetches will run into hard failures. Even if the
635 server bundle(s) are incomplete, or bad in some way the client
636 should still end up with a functioning repository, just as if
637 it had chosen not to use this protocol extension.
638 All subsequent discussion on client and server interaction MUST
640 keep this in mind.
641 bundle-uri SERVER TO CLIENT
643 The ordering of the returned bundle uris is not significant.
644 Clients MUST parse their headers to discover their contained
645 OIDS and prerequisites. A client MUST consider the content of
646 the bundle(s) themselves and their header as the ultimate
647 source of truth.
648 A server MAY even return bundle(s) that don’t have any direct
650 relationship to the repository being cloned (either through
651 accident, or intentional "clever" configuration), and expect a
652 client to sort out what data they’d like from the bundle(s), if
653 any.
654 bundle-uri CLIENT TO SERVER
656 The client SHOULD provide reference tips found in the bundle
657 header(s) as have lines in any subsequent fetch request. A
658 client MAY also ignore the bundle(s) entirely if doing so is
659 deemed worse for some reason, e.g. if the bundles can’t be
660 downloaded, it doesn’t like the tips it finds etc.
661 WHEN ADVERTISED BUNDLE(S) REQUIRE NO FURTHER NEGOTIATION
663 If after issuing bundle-uri and ls-refs, and getting the
664 header(s) of the bundle(s) the client finds that the ref tips
665 it wants can be retrieved entirely from advertised bundle(s),
666 the client MAY disconnect from the Git server. The results of
667 such a clone or fetch should be indistinguishable from the
668 state attained without using bundle-uri.
669 EARLY CLIENT DISCONNECTIONS AND ERROR RECOVERY
671 A client MAY perform an early disconnect while still
672 downloading the bundle(s) (having streamed and parsed their
673 headers). In such a case the client MUST gracefully recover
674 from any errors related to finishing the download and
675 validation of the bundle(s).
676 I.e. a client might need to re-connect and issue a fetch
678 command, and possibly fall back to not making use of bundle-uri
679 at all.
680 This "MAY" behavior is specified as such (and not a "SHOULD")
682 on the assumption that a server advertising bundle uris is more
683 likely than not to be serving up a relatively large repository,
684 and to be pointing to URIs that have a good chance of being in
685 working order. A client MAY e.g. look at the payload size of
686 the bundles as a heuristic to see if an early disconnect is
687 worth it, should falling back on a full "fetch" dialog be
688 necessary.
689 WHEN ADVERTISED BUNDLE(S) REQUIRE FURTHER NEGOTIATION
691 A client SHOULD commence a negotiation of a PACK from the
692 server via the "fetch" command using the OID tips found in
693 advertised bundles, even if’s still in the process of
694 downloading those bundle(s).
695 This allows for aggressive early disconnects from any
697 interactive server dialog. The client blindly trusts that the
698 advertised OID tips are relevant, and issues them as have
699 lines, it then requests any tips it would like (usually from
700 the "ls-refs" advertisement) via want lines. The server will
701 then compute a (hopefully small) PACK with the expected
702 difference between the tips from the bundle(s) and the data
703 requested.
704 The only connection the client then needs to keep active is to
706 the concurrently downloading static bundle(s), when those and
707 the incremental PACK are retrieved they should be inflated and
708 validated. Any errors at this point should be gracefully
709 recovered from, see above.
710 bundle-uri PROTOCOL FEATURES
712 The client constructs a bundle list from the <key>=<value> pairs
713 provided by the server. These pairs are part of the bundle.*
714 namespace as documented in git-config(1). In this section, we
715 discuss some of these keys and describe the actions the client will
716 do in response to this information.
717 In particular, the bundle.version key specifies an integer value.
719 The only accepted value at the moment is 1, but if the client sees
720 an unexpected value here then the client MUST ignore the bundle
721 list.
722 As long as bundle.version is understood, all other unknown keys MAY
724 be ignored by the client. The server will guarantee compatibility
725 with older clients, though newer clients may be better able to use
726 the extra keys to minimize downloads.
727 Any backwards-incompatible addition of pre-URI key-value will be
729 guarded by a new bundle.version value or values in bundle-uri
730 capability advertisement itself, and/or by new future bundle-uri
731 request arguments.
732 Some example key-value pairs that are not currently implemented but
734 could be implemented in the future include:
735 • Add a "hash=<val>" or "size=<bytes>" advertise the expected
737 hash or size of the bundle file.
738 • Advertise that one or more bundle files are the same (to e.g.
740 have clients round-robin or otherwise choose one of N possible
741 files).
742 • A "oid=<OID>" shortcut and "prerequisite=<OID>" shortcut. For
744 expressing the common case of a bundle with one tip and no
745 prerequisites, or one tip and one prerequisite.
746 This would allow for optimizing the common case of servers
748 who’d like to provide one "big bundle" containing only their
749 "main" branch, and/or incremental updates thereof.
750 A client receiving such a a response MAY assume that they can
752 skip retrieving the header from a bundle at the indicated URI,
753 and thus save themselves and the server(s) the request(s)
754 needed to inspect the headers of that bundle or bundles.
755
757 Part of the git(1) suite
758
760 1. api-trace2
761 file:///usr/share/doc/git/technical/api-trace2.html
762Git 2.43.0 11/20/2023 GITPROTOCOL-V2(5)