1GITPROTOCOL-PACK(5)               Git Manual               GITPROTOCOL-PACK(5)
2
3
4

NAME

6       gitprotocol-pack - How packs are transferred over-the-wire
7

SYNOPSIS

9       <over-the-wire-protocol>
10

DESCRIPTION

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
19       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

PKT-LINE FORMAT

28       The descriptions below build on the pkt-line format described in
29       gitprotocol-common(5). When the grammar indicates 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
33       An error packet is a special pkt-line that contains an error string.
34
35             error-line     =  PKT-LINE("ERR" SP explanation-text)
36
37       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

TRANSPORTS

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
49       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
53       The file:// transport runs the upload-pack or receive-pack process
54       locally and communicates with it over a pipe.
55

EXTRA PARAMETERS

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
61       Each Extra Parameter takes the form of <key>=<value> or <key>.
62
63       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

GIT TRANSPORT

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
73           0033git-upload-pack /project.git\0host=myserver.com\0
74
75       The transport may send Extra Parameters by adding an additional NUL
76       byte, and then adding one or more NUL-terminated strings:
77
78           003egit-upload-pack /project.git\0host=myserver.com\0\0version=1\0
79
80           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
89       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
93       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
96           $ echo -e -n \
97             "003agit-upload-pack /schacon/gitbook.git\0host=example.com\0" |
98             nc -v example.com 9418
99

SSH TRANSPORT

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
105           $ ssh git.example.com "git-upload-pack '/project.git'"
106
107       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
113       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
118              git clone ssh://user@example.com/project.git
119             |
120             v
121           ssh user@example.com "git-upload-pack '/project.git'"
122
123       In a "user@host:path" format URI, it’s relative to the user’s home
124       directory, because the Git client will run:
125
126              git clone user@example.com:project.git
127               |
128               v
129           ssh user@example.com "git-upload-pack 'project.git'"
130
131       The exception is if a ~ is used, in which case we execute it without
132       the leading /.
133
134              ssh://user@example.com/~alice/project.git,
135               |
136               v
137           ssh user@example.com "git-upload-pack '~alice/project.git'"
138
139       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
145       A few things to remember here:
146
147       •   The "command name" is spelled with dash (e.g. git-upload-pack), but
148           this can be overridden by the client;
149
150       •   The repository path is always quoted with single quotes.
151

FETCHING DATA FROM A SERVER

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

REFERENCE DISCOVERY

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
164            $ 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
176       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
180       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
184       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
189             advertised-refs  =  *1("version 1")
190                                 (no-refs / list-of-refs)
191                                 *shallow
192                                 flush-pkt
193
194             no-refs          =  PKT-LINE(zero-id SP "capabilities^{}"
195                                 NUL capability-list)
196
197             list-of-refs     =  first-ref *other-ref
198             first-ref        =  PKT-LINE(obj-id SP refname
199                                 NUL capability-list)
200
201             other-ref        =  PKT-LINE(other-tip / other-peeled)
202             other-tip        =  obj-id SP refname
203             other-peeled     =  obj-id SP refname "^{}"
204
205             shallow          =  PKT-LINE("shallow" SP obj-id)
206
207             capability-list  =  capability *(SP capability)
208             capability       =  1*(LC_ALPHA / DIGIT / "-" / "_")
209             LC_ALPHA         =  %x61-7A
210
211       Server and client MUST use lowercase for obj-id, both MUST treat obj-id
212       as case-insensitive.
213
214       See protocol-capabilities.txt for a list of allowed server capabilities
215       and descriptions.
216

PACKFILE NEGOTIATION

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
224       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
231             upload-request    =  want-list
232                                  *shallow-line
233                                  *1depth-request
234                                  [filter-request]
235                                  flush-pkt
236
237             want-list         =  first-want
238                                  *additional-want
239
240             shallow-line      =  PKT-LINE("shallow" SP obj-id)
241
242             depth-request     =  PKT-LINE("deepen" SP depth) /
243                                  PKT-LINE("deepen-since" SP timestamp) /
244                                  PKT-LINE("deepen-not" SP ref)
245
246             first-want        =  PKT-LINE("want" SP obj-id SP capability-list)
247             additional-want   =  PKT-LINE("want" SP obj-id)
248
249             depth             =  1*DIGIT
250
251             filter-request    =  PKT-LINE("filter" SP filter-spec)
252
253       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
258       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
263       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
272       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
279       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
283       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
288             shallow-update   =  *shallow-line
289                                 *unshallow-line
290                                 flush-pkt
291
292             shallow-line     =  PKT-LINE("shallow" SP obj-id)
293
294             unshallow-line   =  PKT-LINE("unshallow" SP obj-id)
295
296       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 starts at the client’s wants.
299
300       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
307       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
315             upload-haves      =  have-list
316                                  compute-end
317
318             have-list         =  *have-line
319             have-line         =  PKT-LINE("have" SP obj-id)
320             compute-end       =  flush-pkt / PKT-LINE("done")
321
322       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
327       In multi_ack mode:
328
329       •   the server will respond with ACK obj-id continue for any common
330           commits.
331
332       •   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
336       •   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
339       In multi_ack_detailed mode:
340
341       •   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
345       Without either multi_ack or multi_ack_detailed:
346
347       •   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
350       •   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
354       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
367       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
372       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
379       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
383       Then the server will start sending its packfile data.
384
385             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
391       A simple clone may look like this (with no have lines):
392
393              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
402              S: 0008NAK\n
403              S: [PACKFILE]
404
405       An incremental update (fetch) response might look like this:
406
407              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
417              S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue\n
418              S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue\n
419              S: 0008NAK\n
420
421              C: 0009done\n
422
423              S: 0031ACK 74730d410fcb6603ace96f1dc55ea6196122532d\n
424              S: [PACKFILE]
425

PACKFILE DATA

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
431       See gitformat-pack(5) for what the packfile itself actually looks like.
432
433       If side-band or side-band-64k capabilities have been specified by the
434       client, the server will send the packfile data multiplexed.
435
436       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
440       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
445       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
450       If no side-band capability was specified, the server will stream the
451       entire packfile without multiplexing.
452

PUSHING DATA TO A SERVER

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

AUTHENTICATION

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

REFERENCE DISCOVERY

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

REFERENCE UPDATE REQUEST AND PACKFILE TRANSFER

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
483       This list is followed by a flush-pkt.
484
485             update-requests   =  *shallow ( command-list | push-cert )
486
487             shallow           =  PKT-LINE("shallow" SP obj-id)
488
489             command-list      =  PKT-LINE(command NUL capability-list)
490                                  *PKT-LINE(command)
491                                  flush-pkt
492
493             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
498             old-id            =  obj-id
499             new-id            =  obj-id
500
501             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
512             push-option       =  1*( VCHAR | SP )
513
514       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
518             push-options      =  *PKT-LINE(push-option) flush-pkt
519
520       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
527       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
530             packfile          =  "PACK" 28*(OCTET)
531
532       If the receiving end does not support delete-refs, the sending end MUST
533       NOT ask for delete command.
534
535       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
540       The packfile MUST NOT be sent if the only command used is delete.
541
542       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
548       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

PUSH CERTIFICATE

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
561       Currently, the following header fields are defined:
562
563       pusher ident
564           Identify the GPG key in "Human Readable Name <email@address>"
565           format.
566
567       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
571       nonce nonce
572           The nonce string the receiving repository asked the pushing user to
573           include in the certificate, to prevent replay attacks.
574
575       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

REPORT STATUS

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
589             report-status     = unpack-status
590                                 1*(command-status)
591                                 flush-pkt
592
593             unpack-status     = PKT-LINE("unpack" SP unpack-result)
594             unpack-result     = "ok" / error-msg
595
596             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
600             error-msg         = 1*(OCTET) ; where not "ok"
601
602       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
609             report-status-v2  = unpack-status
610                                 1*(command-status-v2)
611                                 flush-pkt
612
613             unpack-status     = PKT-LINE("unpack" SP unpack-result)
614             unpack-result     = "ok" / error-msg
615
616             command-status-v2 = command-ok-v2 / command-fail
617             command-ok-v2     = command-ok
618                                 *option-line
619
620             command-ok        = PKT-LINE("ok" SP refname)
621             command-fail      = PKT-LINE("ng" SP refname SP error-msg)
622
623             error-msg         = 1*(OCTET) ; where not "ok"
624
625             option-line       = *1(option-refname)
626                                 *1(option-old-oid)
627                                 *1(option-new-oid)
628                                 *1(option-forced-update)
629
630             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
635       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
642       An example client/server communication might look like this:
643
644              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
650              C: 00677d1665144a3a975c05f1f43902ddaf084e784dbe 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n
651              C: 006874730d410fcb6603ace96f1dc55ea6196122532d 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n
652              C: 0000
653              C: [PACKDATA]
654
655              S: 000eunpack ok\n
656              S: 0018ok refs/heads/debug\n
657              S: 002ang refs/heads/master non-fast-forward\n
658

GIT

660       Part of the git(1) suite
661
662
663
664Git 2.43.0                        11/20/2023               GITPROTOCOL-PACK(5)
Impressum