1GITPROTOCOL-PACK(5) Git Manual GITPROTOCOL-PACK(5)
2
6 gitprotocol-pack - How packs are transferred over-the-wire
7
9 <over-the-wire-protocol>
10
12 Git supports transferring data in packfiles over the ssh://, git://,
13 http:// and file:// transports. There exist two sets of protocols, one
14 for pushing data from a client to a server and another for fetching
15 data from a server to a client. The three transports (ssh, git, file)
16 use the same protocol to transfer data. http is documented in
17 gitprotocol-http(5).
18 The processes invoked in the canonical Git implementation are
20 upload-pack on the server side and fetch-pack on the client side for
21 fetching data; then receive-pack on the server and send-pack on the
22 client for pushing data. The protocol functions to have a server tell a
23 client what is currently on the server, then for the two to negotiate
24 the smallest amount of data to send in order to fully update one or the
25 other.
26
28 The descriptions below build on the pkt-line format described in
29 gitprotocol-common(5). When the grammar indicate PKT-LINE(...), unless
30 otherwise noted the usual pkt-line LF rules apply: the sender SHOULD
31 include a LF, but the receiver MUST NOT complain if it is not present.
32 An error packet is a special pkt-line that contains an error string.
34 error-line = PKT-LINE("ERR" SP explanation-text)
36 Throughout the protocol, where PKT-LINE(...) is expected, an error
38 packet MAY be sent. Once this packet is sent by a client or a server,
39 the data transfer process defined in this protocol is terminated.
40
42 There are three transports over which the packfile protocol is
43 initiated. The Git transport is a simple, unauthenticated server that
44 takes the command (almost always upload-pack, though Git servers can be
45 configured to be globally writable, in which receive- pack initiation
46 is also allowed) with which the client wishes to communicate and
47 executes it and connects it to the requesting process.
48 In the SSH transport, the client just runs the upload-pack or
50 receive-pack process on the server over the SSH protocol and then
51 communicates with that invoked process over the SSH connection.
52 The file:// transport runs the upload-pack or receive-pack process
54 locally and communicates with it over a pipe.
55
57 The protocol provides a mechanism in which clients can send additional
58 information in its first message to the server. These are called "Extra
59 Parameters", and are supported by the Git, SSH, and HTTP protocols.
60 Each Extra Parameter takes the form of <key>=<value> or <key>.
62 Servers that receive any such Extra Parameters MUST ignore all
64 unrecognized keys. Currently, the only Extra Parameter recognized is
65 "version" with a value of 1 or 2. See gitprotocol-v2(5) for more
66 information on protocol version 2.
67
69 The Git transport starts off by sending the command and repository on
70 the wire using the pkt-line format, followed by a NUL byte and a
71 hostname parameter, terminated by a NUL byte.
72 0033git-upload-pack /project.git\0host=myserver.com\0
74 The transport may send Extra Parameters by adding an additional NUL
76 byte, and then adding one or more NUL-terminated strings:
77 003egit-upload-pack /project.git\0host=myserver.com\0\0version=1\0
79 git-proto-request = request-command SP pathname NUL
81 [ host-parameter NUL ] [ NUL extra-parameters ]
82 request-command = "git-upload-pack" / "git-receive-pack" /
83 "git-upload-archive" ; case sensitive
84 pathname = *( %x01-ff ) ; exclude NUL
85 host-parameter = "host=" hostname [ ":" port ]
86 extra-parameters = 1*extra-parameter
87 extra-parameter = 1*( %x01-ff ) NUL
88 host-parameter is used for the git-daemon name based virtual hosting.
90 See --interpolated-path option to git daemon, with the %H/%CH format
91 characters.
92 Basically what the Git client is doing to connect to an upload-pack
94 process on the server side over the Git protocol is this:
95 $ echo -e -n \
97 "003agit-upload-pack /schacon/gitbook.git\0host=example.com\0" |
98 nc -v example.com 9418
99
101 Initiating the upload-pack or receive-pack processes over SSH is
102 executing the binary on the server via SSH remote execution. It is
103 basically equivalent to running this:
104 $ ssh git.example.com "git-upload-pack '/project.git'"
106 For a server to support Git pushing and pulling for a given user over
108 SSH, that user needs to be able to execute one or both of those
109 commands via the SSH shell that they are provided on login. On some
110 systems, that shell access is limited to only being able to run those
111 two commands, or even just one of them.
112 In an ssh:// format URI, it’s absolute in the URI, so the / after the
114 host name (or port number) is sent as an argument, which is then read
115 by the remote git-upload-pack exactly as is, so it’s effectively an
116 absolute path in the remote filesystem.
117 git clone ssh://user@example.com/project.git
119 |
120 v
121 ssh user@example.com "git-upload-pack '/project.git'"
122 In a "user@host:path" format URI, its relative to the user’s home
124 directory, because the Git client will run:
125 git clone user@example.com:project.git
127 |
128 v
129 ssh user@example.com "git-upload-pack 'project.git'"
130 The exception is if a ~ is used, in which case we execute it without
132 the leading /.
133 ssh://user@example.com/~alice/project.git,
135 |
136 v
137 ssh user@example.com "git-upload-pack '~alice/project.git'"
138 Depending on the value of the protocol.version configuration variable,
140 Git may attempt to send Extra Parameters as a colon-separated string in
141 the GIT_PROTOCOL environment variable. This is done only if the
142 ssh.variant configuration variable indicates that the ssh command
143 supports passing environment variables as an argument.
144 A few things to remember here:
146 • The "command name" is spelled with dash (e.g. git-upload-pack), but
148 this can be overridden by the client;
149 • The repository path is always quoted with single quotes.
151
153 When one Git repository wants to get data that a second repository has,
154 the first can fetch from the second. This operation determines what
155 data the server has that the client does not then streams that data
156 down to the client in packfile format.
157
159 When the client initially connects the server will immediately respond
160 with a version number (if "version=1" is sent as an Extra Parameter),
161 and a listing of each reference it has (all branches and tags) along
162 with the object name that each reference currently points to.
163 $ echo -e -n "0045git-upload-pack /schacon/gitbook.git\0host=example.com\0\0version=1\0" |
165 nc -v example.com 9418
166 000eversion 1
167 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack
168 side-band side-band-64k ofs-delta shallow no-progress include-tag
169 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration
170 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master
171 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9
172 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0
173 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{}
174 0000
175 The returned response is a pkt-line stream describing each ref and its
177 current value. The stream MUST be sorted by name according to the C
178 locale ordering.
179 If HEAD is a valid ref, HEAD MUST appear as the first advertised ref.
181 If HEAD is not a valid ref, HEAD MUST NOT appear in the advertisement
182 list at all, but other refs may still appear.
183 The stream MUST include capability declarations behind a NUL on the
185 first ref. The peeled value of a ref (that is "ref^{}") MUST be
186 immediately after the ref itself, if presented. A conforming server
187 MUST peel the ref if it’s an annotated tag.
188 advertised-refs = *1("version 1")
190 (no-refs / list-of-refs)
191 *shallow
192 flush-pkt
193 no-refs = PKT-LINE(zero-id SP "capabilities^{}"
195 NUL capability-list)
196 list-of-refs = first-ref *other-ref
198 first-ref = PKT-LINE(obj-id SP refname
199 NUL capability-list)
200 other-ref = PKT-LINE(other-tip / other-peeled)
202 other-tip = obj-id SP refname
203 other-peeled = obj-id SP refname "^{}"
204 shallow = PKT-LINE("shallow" SP obj-id)
206 capability-list = capability *(SP capability)
208 capability = 1*(LC_ALPHA / DIGIT / "-" / "_")
209 LC_ALPHA = %x61-7A
210 Server and client MUST use lowercase for obj-id, both MUST treat obj-id
212 as case-insensitive.
213 See protocol-capabilities.txt for a list of allowed server capabilities
215 and descriptions.
216
218 After reference and capabilities discovery, the client can decide to
219 terminate the connection by sending a flush-pkt, telling the server it
220 can now gracefully terminate, and disconnect, when it does not need any
221 pack data. This can happen with the ls-remote command, and also can
222 happen when the client already is up to date.
223 Otherwise, it enters the negotiation phase, where the client and server
225 determine what the minimal packfile necessary for transport is, by
226 telling the server what objects it wants, its shallow objects (if any),
227 and the maximum commit depth it wants (if any). The client will also
228 send a list of the capabilities it wants to be in effect, out of what
229 the server said it could do with the first want line.
230 upload-request = want-list
232 *shallow-line
233 *1depth-request
234 [filter-request]
235 flush-pkt
236 want-list = first-want
238 *additional-want
239 shallow-line = PKT-LINE("shallow" SP obj-id)
241 depth-request = PKT-LINE("deepen" SP depth) /
243 PKT-LINE("deepen-since" SP timestamp) /
244 PKT-LINE("deepen-not" SP ref)
245 first-want = PKT-LINE("want" SP obj-id SP capability-list)
247 additional-want = PKT-LINE("want" SP obj-id)
248 depth = 1*DIGIT
250 filter-request = PKT-LINE("filter" SP filter-spec)
252 Clients MUST send all the obj-ids it wants from the reference discovery
254 phase as want lines. Clients MUST send at least one want command in the
255 request body. Clients MUST NOT mention an obj-id in a want command
256 which did not appear in the response obtained through ref discovery.
257 The client MUST write all obj-ids which it only has shallow copies of
259 (meaning that it does not have the parents of a commit) as shallow
260 lines so that the server is aware of the limitations of the client’s
261 history.
262 The client now sends the maximum commit history depth it wants for this
264 transaction, which is the number of commits it wants from the tip of
265 the history, if any, as a deepen line. A depth of 0 is the same as not
266 making a depth request. The client does not want to receive any commits
267 beyond this depth, nor does it want objects needed only to complete
268 those commits. Commits whose parents are not received as a result are
269 defined as shallow and marked as such in the server. This information
270 is sent back to the client in the next step.
271 The client can optionally request that pack-objects omit various
273 objects from the packfile using one of several filtering techniques.
274 These are intended for use with partial clone and partial fetch
275 operations. An object that does not meet a filter-spec value is omitted
276 unless explicitly requested in a want line. See rev-list for possible
277 filter-spec values.
278 Once all the want’s and 'shallow’s (and optional 'deepen) are
280 transferred, clients MUST send a flush-pkt, to tell the server side
281 that it is done sending the list.
282 Otherwise, if the client sent a positive depth request, the server will
284 determine which commits will and will not be shallow and send this
285 information to the client. If the client did not request a positive
286 depth, this step is skipped.
287 shallow-update = *shallow-line
289 *unshallow-line
290 flush-pkt
291 shallow-line = PKT-LINE("shallow" SP obj-id)
293 unshallow-line = PKT-LINE("unshallow" SP obj-id)
295 If the client has requested a positive depth, the server will compute
297 the set of commits which are no deeper than the desired depth. The set
298 of commits start at the client’s wants.
299 The server writes shallow lines for each commit whose parents will not
301 be sent as a result. The server writes an unshallow line for each
302 commit which the client has indicated is shallow, but is no longer
303 shallow at the currently requested depth (that is, its parents will now
304 be sent). The server MUST NOT mark as unshallow anything which the
305 client has not indicated was shallow.
306 Now the client will send a list of the obj-ids it has using have lines,
308 so the server can make a packfile that only contains the objects that
309 the client needs. In multi_ack mode, the canonical implementation will
310 send up to 32 of these at a time, then will send a flush-pkt. The
311 canonical implementation will skip ahead and send the next 32
312 immediately, so that there is always a block of 32 "in-flight on the
313 wire" at a time.
314 upload-haves = have-list
316 compute-end
317 have-list = *have-line
319 have-line = PKT-LINE("have" SP obj-id)
320 compute-end = flush-pkt / PKT-LINE("done")
321 If the server reads have lines, it then will respond by ACKing any of
323 the obj-ids the client said it had that the server also has. The server
324 will ACK obj-ids differently depending on which ack mode is chosen by
325 the client.
326 In multi_ack mode:
328 • the server will respond with ACK obj-id continue for any common
330 commits.
331 • once the server has found an acceptable common base commit and is
333 ready to make a packfile, it will blindly ACK all have obj-ids back
334 to the client.
335 • the server will then send a NAK and then wait for another response
337 from the client - either a done or another list of have lines.
338 In multi_ack_detailed mode:
340 • the server will differentiate the ACKs where it is signaling that
342 it is ready to send data with ACK obj-id ready lines, and signals
343 the identified common commits with ACK obj-id common lines.
344 Without either multi_ack or multi_ack_detailed:
346 • upload-pack sends "ACK obj-id" on the first common object it finds.
348 After that it says nothing until the client gives it a "done".
349 • upload-pack sends "NAK" on a flush-pkt if no common object has been
351 found yet. If one has been found, and thus an ACK was already sent,
352 it’s silent on the flush-pkt.
353 After the client has gotten enough ACK responses that it can determine
355 that the server has enough information to send an efficient packfile
356 (in the canonical implementation, this is determined when it has
357 received enough ACKs that it can color everything left in the
358 --date-order queue as common with the server, or the --date-order queue
359 is empty), or the client determines that it wants to give up (in the
360 canonical implementation, this is determined when the client sends 256
361 have lines without getting any of them ACKed by the server - meaning
362 there is nothing in common and the server should just send all of its
363 objects), then the client will send a done command. The done command
364 signals to the server that the client is ready to receive its packfile
365 data.
366 However, the 256 limit only turns on in the canonical client
368 implementation if we have received at least one "ACK %s continue"
369 during a prior round. This helps to ensure that at least one common
370 ancestor is found before we give up entirely.
371 Once the done line is read from the client, the server will either send
373 a final ACK obj-id or it will send a NAK. obj-id is the object name of
374 the last commit determined to be common. The server only sends ACK
375 after done if there is at least one common base and multi_ack or
376 multi_ack_detailed is enabled. The server always sends NAK after done
377 if there is no common base found.
378 Instead of ACK or NAK, the server may send an error message (for
380 example, if it does not recognize an object in a want line received
381 from the client).
382 Then the server will start sending its packfile data.
384 server-response = *ack_multi ack / nak
386 ack_multi = PKT-LINE("ACK" SP obj-id ack_status)
387 ack_status = "continue" / "common" / "ready"
388 ack = PKT-LINE("ACK" SP obj-id)
389 nak = PKT-LINE("NAK")
390 A simple clone may look like this (with no have lines):
392 C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \
394 side-band-64k ofs-delta\n
395 C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
396 C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
397 C: 0032want 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
398 C: 0032want 74730d410fcb6603ace96f1dc55ea6196122532d\n
399 C: 0000
400 C: 0009done\n
401 S: 0008NAK\n
403 S: [PACKFILE]
404 An incremental update (fetch) response might look like this:
406 C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d multi_ack \
408 side-band-64k ofs-delta\n
409 C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
410 C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
411 C: 0000
412 C: 0032have 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
413 C: [30 more have lines]
414 C: 0032have 74730d410fcb6603ace96f1dc55ea6196122532d\n
415 C: 0000
416 S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue\n
418 S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue\n
419 S: 0008NAK\n
420 C: 0009done\n
422 S: 0031ACK 74730d410fcb6603ace96f1dc55ea6196122532d\n
424 S: [PACKFILE]
425
427 Now that the client and server have finished negotiation about what the
428 minimal amount of data that needs to be sent to the client is, the
429 server will construct and send the required data in packfile format.
430 See gitformat-pack(5) for what the packfile itself actually looks like.
432 If side-band or side-band-64k capabilities have been specified by the
434 client, the server will send the packfile data multiplexed.
435 Each packet starting with the packet-line length of the amount of data
437 that follows, followed by a single byte specifying the sideband the
438 following data is coming in on.
439 In side-band mode, it will send up to 999 data bytes plus 1 control
441 code, for a total of up to 1000 bytes in a pkt-line. In side-band-64k
442 mode it will send up to 65519 data bytes plus 1 control code, for a
443 total of up to 65520 bytes in a pkt-line.
444 The sideband byte will be a 1, 2 or a 3. Sideband 1 will contain
446 packfile data, sideband 2 will be used for progress information that
447 the client will generally print to stderr and sideband 3 is used for
448 error information.
449 If no side-band capability was specified, the server will stream the
451 entire packfile without multiplexing.
452
454 Pushing data to a server will invoke the receive-pack process on the
455 server, which will allow the client to tell it which references it
456 should update and then send all the data the server will need for those
457 new references to be complete. Once all the data is received and
458 validated, the server will then update its references to what the
459 client specified.
460
462 The protocol itself contains no authentication mechanisms. That is to
463 be handled by the transport, such as SSH, before the receive-pack
464 process is invoked. If receive-pack is configured over the Git
465 transport, those repositories will be writable by anyone who can access
466 that port (9418) as that transport is unauthenticated.
467
469 The reference discovery phase is done nearly the same way as it is in
470 the fetching protocol. Each reference obj-id and name on the server is
471 sent in packet-line format to the client, followed by a flush-pkt. The
472 only real difference is that the capability listing is different - the
473 only possible values are report-status, report-status-v2, delete-refs,
474 ofs-delta, atomic and push-options.
475
477 Once the client knows what references the server is at, it can send a
478 list of reference update requests. For each reference on the server
479 that it wants to update, it sends a line listing the obj-id currently
480 on the server, the obj-id the client would like to update it to and the
481 name of the reference.
482 This list is followed by a flush-pkt.
484 update-requests = *shallow ( command-list | push-cert )
486 shallow = PKT-LINE("shallow" SP obj-id)
488 command-list = PKT-LINE(command NUL capability-list)
490 *PKT-LINE(command)
491 flush-pkt
492 command = create / delete / update
494 create = zero-id SP new-id SP name
495 delete = old-id SP zero-id SP name
496 update = old-id SP new-id SP name
497 old-id = obj-id
499 new-id = obj-id
500 push-cert = PKT-LINE("push-cert" NUL capability-list LF)
502 PKT-LINE("certificate version 0.1" LF)
503 PKT-LINE("pusher" SP ident LF)
504 PKT-LINE("pushee" SP url LF)
505 PKT-LINE("nonce" SP nonce LF)
506 *PKT-LINE("push-option" SP push-option LF)
507 PKT-LINE(LF)
508 *PKT-LINE(command LF)
509 *PKT-LINE(gpg-signature-lines LF)
510 PKT-LINE("push-cert-end" LF)
511 push-option = 1*( VCHAR | SP )
513 If the server has advertised the push-options capability and the client
515 has specified push-options as part of the capability list above, the
516 client then sends its push options followed by a flush-pkt.
517 push-options = *PKT-LINE(push-option) flush-pkt
519 For backwards compatibility with older Git servers, if the client sends
521 a push cert and push options, it MUST send its push options both
522 embedded within the push cert and after the push cert. (Note that the
523 push options within the cert are prefixed, but the push options after
524 the cert are not.) Both these lists MUST be the same, modulo the
525 prefix.
526 After that the packfile that should contain all the objects that the
528 server will need to complete the new references will be sent.
529 packfile = "PACK" 28*(OCTET)
531 If the receiving end does not support delete-refs, the sending end MUST
533 NOT ask for delete command.
534 If the receiving end does not support push-cert, the sending end MUST
536 NOT send a push-cert command. When a push-cert command is sent,
537 command-list MUST NOT be sent; the commands recorded in the push
538 certificate is used instead.
539 The packfile MUST NOT be sent if the only command used is delete.
541 A packfile MUST be sent if either create or update command is used,
543 even if the server already has all the necessary objects. In this case
544 the client MUST send an empty packfile. The only time this is likely to
545 happen is if the client is creating a new branch or a tag that points
546 to an existing obj-id.
547 The server will receive the packfile, unpack it, then validate each
549 reference that is being updated that it hasn’t changed while the
550 request was being processed (the obj-id is still the same as the
551 old-id), and it will run any update hooks to make sure that the update
552 is acceptable. If all of that is fine, the server will then update the
553 references.
554
556 A push certificate begins with a set of header lines. After the header
557 and an empty line, the protocol commands follow, one per line. Note
558 that the trailing LF in push-cert PKT-LINEs is not optional; it must be
559 present.
560 Currently, the following header fields are defined:
562 pusher ident
564 Identify the GPG key in "Human Readable Name <email@address>"
565 format.
566 pushee url
568 The repository URL (anonymized, if the URL contains authentication
569 material) the user who ran git push intended to push into.
570 nonce nonce
572 The nonce string the receiving repository asked the pushing user to
573 include in the certificate, to prevent replay attacks.
574 The GPG signature lines are a detached signature for the contents
576 recorded in the push certificate before the signature block begins. The
577 detached signature is used to certify that the commands were given by
578 the pusher, who must be the signer.
579
581 After receiving the pack data from the sender, the receiver sends a
582 report if report-status or report-status-v2 capability is in effect. It
583 is a short listing of what happened in that update. It will first list
584 the status of the packfile unpacking as either unpack ok or unpack
585 [error]. Then it will list the status for each of the references that
586 it tried to update. Each line is either ok [refname] if the update was
587 successful, or ng [refname] [error] if the update was not.
588 report-status = unpack-status
590 1*(command-status)
591 flush-pkt
592 unpack-status = PKT-LINE("unpack" SP unpack-result)
594 unpack-result = "ok" / error-msg
595 command-status = command-ok / command-fail
597 command-ok = PKT-LINE("ok" SP refname)
598 command-fail = PKT-LINE("ng" SP refname SP error-msg)
599 error-msg = 1*(OCTET) ; where not "ok"
601 The report-status-v2 capability extends the protocol by adding new
603 option lines in order to support reporting of reference rewritten by
604 the proc-receive hook. The proc-receive hook may handle a command for a
605 pseudo-reference which may create or update one or more references, and
606 each reference may have different name, different new-oid, and
607 different old-oid.
608 report-status-v2 = unpack-status
610 1*(command-status-v2)
611 flush-pkt
612 unpack-status = PKT-LINE("unpack" SP unpack-result)
614 unpack-result = "ok" / error-msg
615 command-status-v2 = command-ok-v2 / command-fail
617 command-ok-v2 = command-ok
618 *option-line
619 command-ok = PKT-LINE("ok" SP refname)
621 command-fail = PKT-LINE("ng" SP refname SP error-msg)
622 error-msg = 1*(OCTET) ; where not "ok"
624 option-line = *1(option-refname)
626 *1(option-old-oid)
627 *1(option-new-oid)
628 *1(option-forced-update)
629 option-refname = PKT-LINE("option" SP "refname" SP refname)
631 option-old-oid = PKT-LINE("option" SP "old-oid" SP obj-id)
632 option-new-oid = PKT-LINE("option" SP "new-oid" SP obj-id)
633 option-force = PKT-LINE("option" SP "forced-update")
634 Updates can be unsuccessful for a number of reasons. The reference can
636 have changed since the reference discovery phase was originally sent,
637 meaning someone pushed in the meantime. The reference being pushed
638 could be a non-fast-forward reference and the update hooks or
639 configuration could be set to not allow that, etc. Also, some
640 references can be updated while others can be rejected.
641 An example client/server communication might look like this:
643 S: 006274730d410fcb6603ace96f1dc55ea6196122532d refs/heads/local\0report-status delete-refs ofs-delta\n
645 S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug\n
646 S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master\n
647 S: 003d74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n
648 S: 0000
649 C: 00677d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n
651 C: 006874730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n
652 C: 0000
653 C: [PACKDATA]
654 S: 000eunpack ok\n
656 S: 0018ok refs/heads/debug\n
657 S: 002ang refs/heads/master non-fast-forward\n
658
660 Part of the git(1) suite
661Git 2.39.1 2023-01-13 GITPROTOCOL-PACK(5)