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 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
555 Part of the git(1) suite
556
558 1. api-trace2
559 file:///usr/share/doc/git/technical/api-trace2.html
560Git 2.39.1 2023-01-13 GITPROTOCOL-V2(5)