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