| Junio C Hamano | ccb8252 | 2018-05-08 07:52:09 | [diff] [blame] | 1 | <?xml version="1.0" encoding="UTF-8"?> |
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" |
| 3 | "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> |
| 4 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> |
| 5 | <head> |
| 6 | <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" /> |
| 7 | <meta name="generator" content="AsciiDoc 8.6.10" /> |
| 8 | <title> Git Wire Protocol, Version 2</title> |
| 9 | <style type="text/css"> |
| 10 | /* Shared CSS for AsciiDoc xhtml11 and html5 backends */ |
| 11 | |
| 12 | /* Default font. */ |
| 13 | body { |
| 14 | font-family: Georgia,serif; |
| 15 | } |
| 16 | |
| 17 | /* Title font. */ |
| 18 | h1, h2, h3, h4, h5, h6, |
| 19 | div.title, caption.title, |
| 20 | thead, p.table.header, |
| 21 | #toctitle, |
| 22 | #author, #revnumber, #revdate, #revremark, |
| 23 | #footer { |
| 24 | font-family: Arial,Helvetica,sans-serif; |
| 25 | } |
| 26 | |
| 27 | body { |
| 28 | margin: 1em 5% 1em 5%; |
| 29 | } |
| 30 | |
| 31 | a { |
| 32 | color: blue; |
| 33 | text-decoration: underline; |
| 34 | } |
| 35 | a:visited { |
| 36 | color: fuchsia; |
| 37 | } |
| 38 | |
| 39 | em { |
| 40 | font-style: italic; |
| 41 | color: navy; |
| 42 | } |
| 43 | |
| 44 | strong { |
| 45 | font-weight: bold; |
| 46 | color: #083194; |
| 47 | } |
| 48 | |
| 49 | h1, h2, h3, h4, h5, h6 { |
| 50 | color: #527bbd; |
| 51 | margin-top: 1.2em; |
| 52 | margin-bottom: 0.5em; |
| 53 | line-height: 1.3; |
| 54 | } |
| 55 | |
| 56 | h1, h2, h3 { |
| 57 | border-bottom: 2px solid silver; |
| 58 | } |
| 59 | h2 { |
| 60 | padding-top: 0.5em; |
| 61 | } |
| 62 | h3 { |
| 63 | float: left; |
| 64 | } |
| 65 | h3 + * { |
| 66 | clear: left; |
| 67 | } |
| 68 | h5 { |
| 69 | font-size: 1.0em; |
| 70 | } |
| 71 | |
| 72 | div.sectionbody { |
| 73 | margin-left: 0; |
| 74 | } |
| 75 | |
| 76 | hr { |
| 77 | border: 1px solid silver; |
| 78 | } |
| 79 | |
| 80 | p { |
| 81 | margin-top: 0.5em; |
| 82 | margin-bottom: 0.5em; |
| 83 | } |
| 84 | |
| 85 | ul, ol, li > p { |
| 86 | margin-top: 0; |
| 87 | } |
| 88 | ul > li { color: #aaa; } |
| 89 | ul > li > * { color: black; } |
| 90 | |
| 91 | .monospaced, code, pre { |
| 92 | font-family: "Courier New", Courier, monospace; |
| 93 | font-size: inherit; |
| 94 | color: navy; |
| 95 | padding: 0; |
| 96 | margin: 0; |
| 97 | } |
| 98 | pre { |
| 99 | white-space: pre-wrap; |
| 100 | } |
| 101 | |
| 102 | #author { |
| 103 | color: #527bbd; |
| 104 | font-weight: bold; |
| 105 | font-size: 1.1em; |
| 106 | } |
| 107 | #email { |
| 108 | } |
| 109 | #revnumber, #revdate, #revremark { |
| 110 | } |
| 111 | |
| 112 | #footer { |
| 113 | font-size: small; |
| 114 | border-top: 2px solid silver; |
| 115 | padding-top: 0.5em; |
| 116 | margin-top: 4.0em; |
| 117 | } |
| 118 | #footer-text { |
| 119 | float: left; |
| 120 | padding-bottom: 0.5em; |
| 121 | } |
| 122 | #footer-badges { |
| 123 | float: right; |
| 124 | padding-bottom: 0.5em; |
| 125 | } |
| 126 | |
| 127 | #preamble { |
| 128 | margin-top: 1.5em; |
| 129 | margin-bottom: 1.5em; |
| 130 | } |
| 131 | div.imageblock, div.exampleblock, div.verseblock, |
| 132 | div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, |
| 133 | div.admonitionblock { |
| 134 | margin-top: 1.0em; |
| 135 | margin-bottom: 1.5em; |
| 136 | } |
| 137 | div.admonitionblock { |
| 138 | margin-top: 2.0em; |
| 139 | margin-bottom: 2.0em; |
| 140 | margin-right: 10%; |
| 141 | color: #606060; |
| 142 | } |
| 143 | |
| 144 | div.content { /* Block element content. */ |
| 145 | padding: 0; |
| 146 | } |
| 147 | |
| 148 | /* Block element titles. */ |
| 149 | div.title, caption.title { |
| 150 | color: #527bbd; |
| 151 | font-weight: bold; |
| 152 | text-align: left; |
| 153 | margin-top: 1.0em; |
| 154 | margin-bottom: 0.5em; |
| 155 | } |
| 156 | div.title + * { |
| 157 | margin-top: 0; |
| 158 | } |
| 159 | |
| 160 | td div.title:first-child { |
| 161 | margin-top: 0.0em; |
| 162 | } |
| 163 | div.content div.title:first-child { |
| 164 | margin-top: 0.0em; |
| 165 | } |
| 166 | div.content + div.title { |
| 167 | margin-top: 0.0em; |
| 168 | } |
| 169 | |
| 170 | div.sidebarblock > div.content { |
| 171 | background: #ffffee; |
| 172 | border: 1px solid #dddddd; |
| 173 | border-left: 4px solid #f0f0f0; |
| 174 | padding: 0.5em; |
| 175 | } |
| 176 | |
| 177 | div.listingblock > div.content { |
| 178 | border: 1px solid #dddddd; |
| 179 | border-left: 5px solid #f0f0f0; |
| 180 | background: #f8f8f8; |
| 181 | padding: 0.5em; |
| 182 | } |
| 183 | |
| 184 | div.quoteblock, div.verseblock { |
| 185 | padding-left: 1.0em; |
| 186 | margin-left: 1.0em; |
| 187 | margin-right: 10%; |
| 188 | border-left: 5px solid #f0f0f0; |
| 189 | color: #888; |
| 190 | } |
| 191 | |
| 192 | div.quoteblock > div.attribution { |
| 193 | padding-top: 0.5em; |
| 194 | text-align: right; |
| 195 | } |
| 196 | |
| 197 | div.verseblock > pre.content { |
| 198 | font-family: inherit; |
| 199 | font-size: inherit; |
| 200 | } |
| 201 | div.verseblock > div.attribution { |
| 202 | padding-top: 0.75em; |
| 203 | text-align: left; |
| 204 | } |
| 205 | /* DEPRECATED: Pre version 8.2.7 verse style literal block. */ |
| 206 | div.verseblock + div.attribution { |
| 207 | text-align: left; |
| 208 | } |
| 209 | |
| 210 | div.admonitionblock .icon { |
| 211 | vertical-align: top; |
| 212 | font-size: 1.1em; |
| 213 | font-weight: bold; |
| 214 | text-decoration: underline; |
| 215 | color: #527bbd; |
| 216 | padding-right: 0.5em; |
| 217 | } |
| 218 | div.admonitionblock td.content { |
| 219 | padding-left: 0.5em; |
| 220 | border-left: 3px solid #dddddd; |
| 221 | } |
| 222 | |
| 223 | div.exampleblock > div.content { |
| 224 | border-left: 3px solid #dddddd; |
| 225 | padding-left: 0.5em; |
| 226 | } |
| 227 | |
| 228 | div.imageblock div.content { padding-left: 0; } |
| 229 | span.image img { border-style: none; vertical-align: text-bottom; } |
| 230 | a.image:visited { color: white; } |
| 231 | |
| 232 | dl { |
| 233 | margin-top: 0.8em; |
| 234 | margin-bottom: 0.8em; |
| 235 | } |
| 236 | dt { |
| 237 | margin-top: 0.5em; |
| 238 | margin-bottom: 0; |
| 239 | font-style: normal; |
| 240 | color: navy; |
| 241 | } |
| 242 | dd > *:first-child { |
| 243 | margin-top: 0.1em; |
| 244 | } |
| 245 | |
| 246 | ul, ol { |
| 247 | list-style-position: outside; |
| 248 | } |
| 249 | ol.arabic { |
| 250 | list-style-type: decimal; |
| 251 | } |
| 252 | ol.loweralpha { |
| 253 | list-style-type: lower-alpha; |
| 254 | } |
| 255 | ol.upperalpha { |
| 256 | list-style-type: upper-alpha; |
| 257 | } |
| 258 | ol.lowerroman { |
| 259 | list-style-type: lower-roman; |
| 260 | } |
| 261 | ol.upperroman { |
| 262 | list-style-type: upper-roman; |
| 263 | } |
| 264 | |
| 265 | div.compact ul, div.compact ol, |
| 266 | div.compact p, div.compact p, |
| 267 | div.compact div, div.compact div { |
| 268 | margin-top: 0.1em; |
| 269 | margin-bottom: 0.1em; |
| 270 | } |
| 271 | |
| 272 | tfoot { |
| 273 | font-weight: bold; |
| 274 | } |
| 275 | td > div.verse { |
| 276 | white-space: pre; |
| 277 | } |
| 278 | |
| 279 | div.hdlist { |
| 280 | margin-top: 0.8em; |
| 281 | margin-bottom: 0.8em; |
| 282 | } |
| 283 | div.hdlist tr { |
| 284 | padding-bottom: 15px; |
| 285 | } |
| 286 | dt.hdlist1.strong, td.hdlist1.strong { |
| 287 | font-weight: bold; |
| 288 | } |
| 289 | td.hdlist1 { |
| 290 | vertical-align: top; |
| 291 | font-style: normal; |
| 292 | padding-right: 0.8em; |
| 293 | color: navy; |
| 294 | } |
| 295 | td.hdlist2 { |
| 296 | vertical-align: top; |
| 297 | } |
| 298 | div.hdlist.compact tr { |
| 299 | margin: 0; |
| 300 | padding-bottom: 0; |
| 301 | } |
| 302 | |
| 303 | .comment { |
| 304 | background: yellow; |
| 305 | } |
| 306 | |
| 307 | .footnote, .footnoteref { |
| 308 | font-size: 0.8em; |
| 309 | } |
| 310 | |
| 311 | span.footnote, span.footnoteref { |
| 312 | vertical-align: super; |
| 313 | } |
| 314 | |
| 315 | #footnotes { |
| 316 | margin: 20px 0 20px 0; |
| 317 | padding: 7px 0 0 0; |
| 318 | } |
| 319 | |
| 320 | #footnotes div.footnote { |
| 321 | margin: 0 0 5px 0; |
| 322 | } |
| 323 | |
| 324 | #footnotes hr { |
| 325 | border: none; |
| 326 | border-top: 1px solid silver; |
| 327 | height: 1px; |
| 328 | text-align: left; |
| 329 | margin-left: 0; |
| 330 | width: 20%; |
| 331 | min-width: 100px; |
| 332 | } |
| 333 | |
| 334 | div.colist td { |
| 335 | padding-right: 0.5em; |
| 336 | padding-bottom: 0.3em; |
| 337 | vertical-align: top; |
| 338 | } |
| 339 | div.colist td img { |
| 340 | margin-top: 0.3em; |
| 341 | } |
| 342 | |
| 343 | @media print { |
| 344 | #footer-badges { display: none; } |
| 345 | } |
| 346 | |
| 347 | #toc { |
| 348 | margin-bottom: 2.5em; |
| 349 | } |
| 350 | |
| 351 | #toctitle { |
| 352 | color: #527bbd; |
| 353 | font-size: 1.1em; |
| 354 | font-weight: bold; |
| 355 | margin-top: 1.0em; |
| 356 | margin-bottom: 0.1em; |
| 357 | } |
| 358 | |
| 359 | div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 { |
| 360 | margin-top: 0; |
| 361 | margin-bottom: 0; |
| 362 | } |
| 363 | div.toclevel2 { |
| 364 | margin-left: 2em; |
| 365 | font-size: 0.9em; |
| 366 | } |
| 367 | div.toclevel3 { |
| 368 | margin-left: 4em; |
| 369 | font-size: 0.9em; |
| 370 | } |
| 371 | div.toclevel4 { |
| 372 | margin-left: 6em; |
| 373 | font-size: 0.9em; |
| 374 | } |
| 375 | |
| 376 | span.aqua { color: aqua; } |
| 377 | span.black { color: black; } |
| 378 | span.blue { color: blue; } |
| 379 | span.fuchsia { color: fuchsia; } |
| 380 | span.gray { color: gray; } |
| 381 | span.green { color: green; } |
| 382 | span.lime { color: lime; } |
| 383 | span.maroon { color: maroon; } |
| 384 | span.navy { color: navy; } |
| 385 | span.olive { color: olive; } |
| 386 | span.purple { color: purple; } |
| 387 | span.red { color: red; } |
| 388 | span.silver { color: silver; } |
| 389 | span.teal { color: teal; } |
| 390 | span.white { color: white; } |
| 391 | span.yellow { color: yellow; } |
| 392 | |
| 393 | span.aqua-background { background: aqua; } |
| 394 | span.black-background { background: black; } |
| 395 | span.blue-background { background: blue; } |
| 396 | span.fuchsia-background { background: fuchsia; } |
| 397 | span.gray-background { background: gray; } |
| 398 | span.green-background { background: green; } |
| 399 | span.lime-background { background: lime; } |
| 400 | span.maroon-background { background: maroon; } |
| 401 | span.navy-background { background: navy; } |
| 402 | span.olive-background { background: olive; } |
| 403 | span.purple-background { background: purple; } |
| 404 | span.red-background { background: red; } |
| 405 | span.silver-background { background: silver; } |
| 406 | span.teal-background { background: teal; } |
| 407 | span.white-background { background: white; } |
| 408 | span.yellow-background { background: yellow; } |
| 409 | |
| 410 | span.big { font-size: 2em; } |
| 411 | span.small { font-size: 0.6em; } |
| 412 | |
| 413 | span.underline { text-decoration: underline; } |
| 414 | span.overline { text-decoration: overline; } |
| 415 | span.line-through { text-decoration: line-through; } |
| 416 | |
| 417 | div.unbreakable { page-break-inside: avoid; } |
| 418 | |
| 419 | |
| 420 | /* |
| 421 | * xhtml11 specific |
| 422 | * |
| 423 | * */ |
| 424 | |
| 425 | div.tableblock { |
| 426 | margin-top: 1.0em; |
| 427 | margin-bottom: 1.5em; |
| 428 | } |
| 429 | div.tableblock > table { |
| 430 | border: 3px solid #527bbd; |
| 431 | } |
| 432 | thead, p.table.header { |
| 433 | font-weight: bold; |
| 434 | color: #527bbd; |
| 435 | } |
| 436 | p.table { |
| 437 | margin-top: 0; |
| 438 | } |
| 439 | /* Because the table frame attribute is overriden by CSS in most browsers. */ |
| 440 | div.tableblock > table[frame="void"] { |
| 441 | border-style: none; |
| 442 | } |
| 443 | div.tableblock > table[frame="hsides"] { |
| 444 | border-left-style: none; |
| 445 | border-right-style: none; |
| 446 | } |
| 447 | div.tableblock > table[frame="vsides"] { |
| 448 | border-top-style: none; |
| 449 | border-bottom-style: none; |
| 450 | } |
| 451 | |
| 452 | |
| 453 | /* |
| 454 | * html5 specific |
| 455 | * |
| 456 | * */ |
| 457 | |
| 458 | table.tableblock { |
| 459 | margin-top: 1.0em; |
| 460 | margin-bottom: 1.5em; |
| 461 | } |
| 462 | thead, p.tableblock.header { |
| 463 | font-weight: bold; |
| 464 | color: #527bbd; |
| 465 | } |
| 466 | p.tableblock { |
| 467 | margin-top: 0; |
| 468 | } |
| 469 | table.tableblock { |
| 470 | border-width: 3px; |
| 471 | border-spacing: 0px; |
| 472 | border-style: solid; |
| 473 | border-color: #527bbd; |
| 474 | border-collapse: collapse; |
| 475 | } |
| 476 | th.tableblock, td.tableblock { |
| 477 | border-width: 1px; |
| 478 | padding: 4px; |
| 479 | border-style: solid; |
| 480 | border-color: #527bbd; |
| 481 | } |
| 482 | |
| 483 | table.tableblock.frame-topbot { |
| 484 | border-left-style: hidden; |
| 485 | border-right-style: hidden; |
| 486 | } |
| 487 | table.tableblock.frame-sides { |
| 488 | border-top-style: hidden; |
| 489 | border-bottom-style: hidden; |
| 490 | } |
| 491 | table.tableblock.frame-none { |
| 492 | border-style: hidden; |
| 493 | } |
| 494 | |
| 495 | th.tableblock.halign-left, td.tableblock.halign-left { |
| 496 | text-align: left; |
| 497 | } |
| 498 | th.tableblock.halign-center, td.tableblock.halign-center { |
| 499 | text-align: center; |
| 500 | } |
| 501 | th.tableblock.halign-right, td.tableblock.halign-right { |
| 502 | text-align: right; |
| 503 | } |
| 504 | |
| 505 | th.tableblock.valign-top, td.tableblock.valign-top { |
| 506 | vertical-align: top; |
| 507 | } |
| 508 | th.tableblock.valign-middle, td.tableblock.valign-middle { |
| 509 | vertical-align: middle; |
| 510 | } |
| 511 | th.tableblock.valign-bottom, td.tableblock.valign-bottom { |
| 512 | vertical-align: bottom; |
| 513 | } |
| 514 | |
| 515 | |
| 516 | /* |
| 517 | * manpage specific |
| 518 | * |
| 519 | * */ |
| 520 | |
| 521 | body.manpage h1 { |
| 522 | padding-top: 0.5em; |
| 523 | padding-bottom: 0.5em; |
| 524 | border-top: 2px solid silver; |
| 525 | border-bottom: 2px solid silver; |
| 526 | } |
| 527 | body.manpage h2 { |
| 528 | border-style: none; |
| 529 | } |
| 530 | body.manpage div.sectionbody { |
| 531 | margin-left: 3em; |
| 532 | } |
| 533 | |
| 534 | @media print { |
| 535 | body.manpage div#toc { display: none; } |
| 536 | } |
| 537 | |
| 538 | |
| 539 | </style> |
| 540 | <script type="text/javascript"> |
| 541 | /*<+'])'); |
| 584 | // Function that scans the DOM tree for header elements (the DOM2 |
| 585 | // nodeIterator API would be a better technique but not supported by all |
| 586 | // browsers). |
| 587 | var iterate = function (el) { |
| 588 | for (var i = el.firstChild; i != null; i = i.nextSibling) { |
| 589 | if (i.nodeType == 1 /* Node.ELEMENT_NODE */) { |
| 590 | var mo = re.exec(i.tagName); |
| 591 | if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") { |
| 592 | result[result.length] = new TocEntry(i, getText(i), mo[1]-1); |
| 593 | } |
| 594 | iterate(i); |
| 595 | } |
| 596 | } |
| 597 | } |
| 598 | iterate(el); |
| 599 | return result; |
| 600 | } |
| 601 | |
| 602 | var toc = document.getElementById("toc"); |
| 603 | if (!toc) { |
| 604 | return; |
| 605 | } |
| 606 | |
| 607 | // Delete existing TOC entries in case we're reloading the TOC. |
| 608 | var tocEntriesToRemove = []; |
| 609 | var i; |
| 610 | for (i = 0; i < toc.childNodes.length; i++) { |
| 611 | var entry = toc.childNodes[i]; |
| 612 | if (entry.nodeName.toLowerCase() == 'div' |
| 613 | && entry.getAttribute("class") |
| 614 | && entry.getAttribute("class").match(/^toclevel/)) |
| 615 | tocEntriesToRemove.push(entry); |
| 616 | } |
| 617 | for (i = 0; i < tocEntriesToRemove.length; i++) { |
| 618 | toc.removeChild(tocEntriesToRemove[i]); |
| 619 | } |
| 620 | |
| 621 | // Rebuild TOC entries. |
| 622 | var entries = tocEntries(document.getElementById("content"), toclevels); |
| 623 | for (var i = 0; i < entries.length; ++i) { |
| 624 | var entry = entries[i]; |
| 625 | if (entry.element.id == "") |
| 626 | entry.element.id = "_toc_" + i; |
| 627 | var a = document.createElement("a"); |
| 628 | a.href = "#" + entry.element.id; |
| 629 | a.appendChild(document.createTextNode(entry.text)); |
| 630 | var div = document.createElement("div"); |
| 631 | div.appendChild(a); |
| 632 | div.className = "toclevel" + entry.toclevel; |
| 633 | toc.appendChild(div); |
| 634 | } |
| 635 | if (entries.length == 0) |
| 636 | toc.parentNode.removeChild(toc); |
| 637 | }, |
| 638 | |
| 639 | |
| 640 | ///////////////////////////////////////////////////////////////////// |
| 641 | // Footnotes generator |
| 642 | ///////////////////////////////////////////////////////////////////// |
| 643 | |
| 644 | /* Based on footnote generation code from: |
| 645 | * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html |
| 646 | */ |
| 647 | |
| 648 | footnotes: function () { |
| 649 | // Delete existing footnote entries in case we're reloading the footnodes. |
| 650 | var i; |
| 651 | var noteholder = document.getElementById("footnotes"); |
| 652 | if (!noteholder) { |
| 653 | return; |
| 654 | } |
| 655 | var entriesToRemove = []; |
| 656 | for (i = 0; i < noteholder.childNodes.length; i++) { |
| 657 | var entry = noteholder.childNodes[i]; |
| 658 | if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote") |
| 659 | entriesToRemove.push(entry); |
| 660 | } |
| 661 | for (i = 0; i < entriesToRemove.length; i++) { |
| 662 | noteholder.removeChild(entriesToRemove[i]); |
| 663 | } |
| 664 | |
| 665 | // Rebuild footnote entries. |
| 666 | var cont = document.getElementById("content"); |
| 667 | var spans = cont.getElementsByTagName("span"); |
| 668 | var refs = {}; |
| 669 | var n = 0; |
| 670 | for (i=0; i<spans.length; i++) { |
| 671 | if (spans[i].className == "footnote") { |
| 672 | n++; |
| 673 | var note = spans[i].getAttribute("data-note"); |
| 674 | if (!note) { |
| 675 | // Use [\s\S] in place of . so multi-line matches work. |
| 676 | // Because JavaScript has no s (dotall) regex flag. |
| 677 | note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1]; |
| 678 | spans[i].innerHTML = |
| 679 | "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n + |
| 680 | "' title='View footnote' class='footnote'>" + n + "</a>]"; |
| 681 | spans[i].setAttribute("data-note", note); |
| 682 | } |
| 683 | noteholder.innerHTML += |
| 684 | "<div class='footnote' id='_footnote_" + n + "'>" + |
| 685 | "<a href='#_footnoteref_" + n + "' title='Return to text'>" + |
| 686 | n + "</a>. " + note + "</div>"; |
| 687 | var id =spans[i].getAttribute("id"); |
| 688 | if (id != null) refs["#"+id] = n; |
| 689 | } |
| 690 | } |
| 691 | if (n == 0) |
| 692 | noteholder.parentNode.removeChild(noteholder); |
| 693 | else { |
| 694 | // Process footnoterefs. |
| 695 | for (i=0; i<spans.length; i++) { |
| 696 | if (spans[i].className == "footnoteref") { |
| 697 | var href = spans[i].getElementsByTagName("a")[0].getAttribute("href"); |
| 698 | href = href.match(/#.*/)[0]; // Because IE return full URL. |
| 699 | n = refs[href]; |
| 700 | spans[i].innerHTML = |
| 701 | "[<a href='#_footnote_" + n + |
| 702 | "' title='View footnote' class='footnote'>" + n + "</a>]"; |
| 703 | } |
| 704 | } |
| 705 | } |
| 706 | }, |
| 707 | |
| 708 | install: function(toclevels) { |
| 709 | var timerId; |
| 710 | |
| 711 | function reinstall() { |
| 712 | asciidoc.footnotes(); |
| 713 | if (toclevels) { |
| 714 | asciidoc.toc(toclevels); |
| 715 | } |
| 716 | } |
| 717 | |
| 718 | function reinstallAndRemoveTimer() { |
| 719 | clearInterval(timerId); |
| 720 | reinstall(); |
| 721 | } |
| 722 | |
| 723 | timerId = setInterval(reinstall, 500); |
| 724 | if (document.addEventListener) |
| 725 | document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false); |
| 726 | else |
| 727 | window.onload = reinstallAndRemoveTimer; |
| 728 | } |
| 729 | |
| 730 | } |
| 731 | asciidoc.install(); |
| 732 | /*]]>*/ |
| 733 | </script> |
| 734 | </head> |
| 735 | <body class="article"> |
| 736 | <div id="header"> |
| 737 | <h1> Git Wire Protocol, Version 2</h1> |
| 738 | </div> |
| 739 | <div id="content"> |
| 740 | <div id="preamble"> |
| 741 | <div class="sectionbody"> |
| 742 | <div class="paragraph"><p>This document presents a specification for a version 2 of Git’s wire |
| 743 | protocol. Protocol v2 will improve upon v1 in the following ways:</p></div> |
| 744 | <div class="ulist"><ul> |
| 745 | <li> |
| 746 | <p> |
| 747 | Instead of multiple service names, multiple commands will be |
| 748 | supported by a single service |
| 749 | </p> |
| 750 | </li> |
| 751 | <li> |
| 752 | <p> |
| 753 | Easily extendable as capabilities are moved into their own section |
| 754 | of the protocol, no longer being hidden behind a NUL byte and |
| 755 | limited by the size of a pkt-line |
| 756 | </p> |
| 757 | </li> |
| 758 | <li> |
| 759 | <p> |
| 760 | Separate out other information hidden behind NUL bytes (e.g. agent |
| 761 | string as a capability and symrefs can be requested using <em>ls-refs</em>) |
| 762 | </p> |
| 763 | </li> |
| 764 | <li> |
| 765 | <p> |
| 766 | Reference advertisement will be omitted unless explicitly requested |
| 767 | </p> |
| 768 | </li> |
| 769 | <li> |
| 770 | <p> |
| 771 | ls-refs command to explicitly request some refs |
| 772 | </p> |
| 773 | </li> |
| 774 | <li> |
| 775 | <p> |
| 776 | Designed with http and stateless-rpc in mind. With clear flush |
| 777 | semantics the http remote helper can simply act as a proxy |
| 778 | </p> |
| 779 | </li> |
| 780 | </ul></div> |
| 781 | <div class="paragraph"><p>In protocol v2 communication is command oriented. When first contacting a |
| 782 | server a list of capabilities will advertised. Some of these capabilities |
| 783 | will be commands which a client can request be executed. Once a command |
| 784 | has completed, a client can reuse the connection and request that other |
| 785 | commands be executed.</p></div> |
| 786 | </div> |
| 787 | </div> |
| 788 | <div class="sect1"> |
| 789 | <h2 id="_packet_line_framing"> Packet-Line Framing</h2> |
| 790 | <div class="sectionbody"> |
| 791 | <div class="paragraph"><p>All communication is done using packet-line framing, just as in v1. See |
| 792 | <code>Documentation/technical/pack-protocol.txt</code> and |
| 793 | <code>Documentation/technical/protocol-common.txt</code> for more information.</p></div> |
| 794 | <div class="paragraph"><p>In protocol v2 these special packets will have the following semantics:</p></div> |
| 795 | <div class="ulist"><ul> |
| 796 | <li> |
| 797 | <p> |
| 798 | <em>0000</em> Flush Packet (flush-pkt) - indicates the end of a message |
| 799 | </p> |
| 800 | </li> |
| 801 | <li> |
| 802 | <p> |
| 803 | <em>0001</em> Delimiter Packet (delim-pkt) - separates sections of a message |
| 804 | </p> |
| 805 | </li> |
| 806 | </ul></div> |
| 807 | </div> |
| 808 | </div> |
| 809 | <div class="sect1"> |
| 810 | <h2 id="_initial_client_request"> Initial Client Request</h2> |
| 811 | <div class="sectionbody"> |
| 812 | <div class="paragraph"><p>In general a client can request to speak protocol v2 by sending |
| 813 | <code>version=2</code> through the respective side-channel for the transport being |
| 814 | used which inevitably sets <code>GIT_PROTOCOL</code>. More information can be |
| 815 | found in <code>pack-protocol.txt</code> and <code>http-protocol.txt</code>. In all cases the |
| 816 | response from the server is the capability advertisement.</p></div> |
| 817 | <div class="sect2"> |
| 818 | <h3 id="_git_transport"> Git Transport</h3> |
| 819 | <div class="paragraph"><p>When using the git:// transport, you can request to use protocol v2 by |
| 820 | sending "version=2" as an extra parameter:</p></div> |
| 821 | <div class="literalblock"> |
| 822 | <div class="content"> |
| 823 | <pre><code>003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0</code></pre> |
| 824 | </div></div> |
| 825 | </div> |
| 826 | <div class="sect2"> |
| 827 | <h3 id="_ssh_and_file_transport"> SSH and File Transport</h3> |
| 828 | <div class="paragraph"><p>When using either the ssh:// or file:// transport, the GIT_PROTOCOL |
| 829 | environment variable must be set explicitly to include "version=2".</p></div> |
| 830 | </div> |
| 831 | <div class="sect2"> |
| 832 | <h3 id="_http_transport"> HTTP Transport</h3> |
| 833 | <div class="paragraph"><p>When using the http:// or https:// transport a client makes a "smart" |
| 834 | info/refs request as described in <code>http-protocol.txt</code> and requests that |
| 835 | v2 be used by supplying "version=2" in the <code>Git-Protocol</code> header.</p></div> |
| 836 | <div class="literalblock"> |
| 837 | <div class="content"> |
| 838 | <pre><code>C: Git-Protocol: version=2 |
| 839 | C: |
| 840 | C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0</code></pre> |
| 841 | </div></div> |
| 842 | <div class="paragraph"><p>A v2 server would reply:</p></div> |
| 843 | <div class="literalblock"> |
| 844 | <div class="content"> |
| 845 | <pre><code>S: 200 OK |
| 846 | S: <Some headers> |
| 847 | S: ... |
| 848 | S: |
| 849 | S: 000eversion 2\n |
| 850 | S: <capability-advertisement></code></pre> |
| 851 | </div></div> |
| 852 | <div class="paragraph"><p>Subsequent requests are then made directly to the service |
| 853 | <code>$GIT_URL/git-upload-pack</code>. (This works the same for git-receive-pack).</p></div> |
| 854 | </div> |
| 855 | </div> |
| 856 | </div> |
| 857 | <div class="sect1"> |
| 858 | <h2 id="_capability_advertisement"> Capability Advertisement</h2> |
| 859 | <div class="sectionbody"> |
| 860 | <div class="paragraph"><p>A server which decides to communicate (based on a request from a client) |
| 861 | using protocol version 2, notifies the client by sending a version string |
| 862 | in its initial response followed by an advertisement of its capabilities. |
| 863 | Each capability is a key with an optional value. Clients must ignore all |
| 864 | unknown keys. Semantics of unknown values are left to the definition of |
| 865 | each key. Some capabilities will describe commands which can be requested |
| 866 | to be executed by the client.</p></div> |
| 867 | <div class="literalblock"> |
| 868 | <div class="content"> |
| 869 | <pre><code>capability-advertisement = protocol-version |
| 870 | capability-list |
| 871 | flush-pkt</code></pre> |
| 872 | </div></div> |
| 873 | <div class="literalblock"> |
| 874 | <div class="content"> |
| 875 | <pre><code>protocol-version = PKT-LINE("version 2" LF) |
| 876 | capability-list = *capability |
| 877 | capability = PKT-LINE(key[=value] LF)</code></pre> |
| 878 | </div></div> |
| 879 | <div class="literalblock"> |
| 880 | <div class="content"> |
| 881 | <pre><code>key = 1*(ALPHA | DIGIT | "-_") |
| 882 | value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")</code></pre> |
| 883 | </div></div> |
| 884 | </div> |
| 885 | </div> |
| 886 | <div class="sect1"> |
| 887 | <h2 id="_command_request"> Command Request</h2> |
| 888 | <div class="sectionbody"> |
| 889 | <div class="paragraph"><p>After receiving the capability advertisement, a client can then issue a |
| 890 | request to select the command it wants with any particular capabilities |
| 891 | or arguments. There is then an optional section where the client can |
| 892 | provide any command specific parameters or queries. Only a single |
| 893 | command can be requested at a time.</p></div> |
| 894 | <div class="literalblock"> |
| 895 | <div class="content"> |
| 896 | <pre><code>request = empty-request | command-request |
| 897 | empty-request = flush-pkt |
| 898 | command-request = command |
| 899 | capability-list |
| 900 | [command-args] |
| 901 | flush-pkt |
| 902 | command = PKT-LINE("command=" key LF) |
| 903 | command-args = delim-pkt |
| 904 | *command-specific-arg</code></pre> |
| 905 | </div></div> |
| 906 | <div class="literalblock"> |
| 907 | <div class="content"> |
| 908 | <pre><code>command-specific-args are packet line framed arguments defined by |
| 909 | each individual command.</code></pre> |
| 910 | </div></div> |
| 911 | <div class="paragraph"><p>The server will then check to ensure that the client’s request is |
| 912 | comprised of a valid command as well as valid capabilities which were |
| 913 | advertised. If the request is valid the server will then execute the |
| 914 | command. A server MUST wait till it has received the client’s entire |
| 915 | request before issuing a response. The format of the response is |
| 916 | determined by the command being executed, but in all cases a flush-pkt |
| 917 | indicates the end of the response.</p></div> |
| 918 | <div class="paragraph"><p>When a command has finished, and the client has received the entire |
| 919 | response from the server, a client can either request that another |
| 920 | command be executed or can terminate the connection. A client may |
| 921 | optionally send an empty request consisting of just a flush-pkt to |
| 922 | indicate that no more requests will be made.</p></div> |
| 923 | </div> |
| 924 | </div> |
| 925 | <div class="sect1"> |
| 926 | <h2 id="_capabilities"> Capabilities</h2> |
| 927 | <div class="sectionbody"> |
| 928 | <div class="paragraph"><p>There are two different types of capabilities: normal capabilities, |
| 929 | which can be used to to convey information or alter the behavior of a |
| 930 | request, and commands, which are the core actions that a client wants to |
| 931 | perform (fetch, push, etc).</p></div> |
| 932 | <div class="paragraph"><p>Protocol version 2 is stateless by default. This means that all commands |
| 933 | must only last a single round and be stateless from the perspective of the |
| 934 | server side, unless the client has requested a capability indicating that |
| 935 | state should be maintained by the server. Clients MUST NOT require state |
| 936 | management on the server side in order to function correctly. This |
| 937 | permits simple round-robin load-balancing on the server side, without |
| 938 | needing to worry about state management.</p></div> |
| 939 | <div class="sect2"> |
| 940 | <h3 id="_agent"> agent</h3> |
| 941 | <div class="paragraph"><p>The server can advertise the <code>agent</code> capability with a value <code>X</code> (in the |
| 942 | form <code>agent=X</code>) to notify the client that the server is running version |
| 943 | <code>X</code>. The client may optionally send its own agent string by including |
| 944 | the <code>agent</code> capability with a value <code>Y</code> (in the form <code>agent=Y</code>) in its |
| 945 | request to the server (but it MUST NOT do so if the server did not |
| 946 | advertise the agent capability). The <code>X</code> and <code>Y</code> strings may contain any |
| 947 | printable ASCII characters except space (i.e., the byte range 32 < x < |
| 948 | 127), and are typically of the form "package/version" (e.g., |
| 949 | "git/1.8.3.1"). The agent strings are purely informative for statistics |
| 950 | and debugging purposes, and MUST NOT be used to programmatically assume |
| 951 | the presence or absence of particular features.</p></div> |
| 952 | </div> |
| 953 | <div class="sect2"> |
| 954 | <h3 id="_ls_refs"> ls-refs</h3> |
| 955 | <div class="paragraph"><p><code>ls-refs</code> is the command used to request a reference advertisement in v2. |
| 956 | Unlike the current reference advertisement, ls-refs takes in arguments |
| 957 | which can be used to limit the refs sent from the server.</p></div> |
| 958 | <div class="paragraph"><p>Additional features not supported in the base command will be advertised |
| 959 | as the value of the command in the capability advertisement in the form |
| 960 | of a space separated list of features: "<command>=<feature 1> <feature 2>"</p></div> |
| 961 | <div class="paragraph"><p>ls-refs takes in the following arguments:</p></div> |
| 962 | <div class="literalblock"> |
| 963 | <div class="content"> |
| 964 | <pre><code>symrefs |
| 965 | In addition to the object pointed by it, show the underlying ref |
| 966 | pointed by it when showing a symbolic ref. |
| 967 | peel |
| 968 | Show peeled tags. |
| 969 | ref-prefix <prefix> |
| 970 | When specified, only references having a prefix matching one of |
| 971 | the provided prefixes are displayed.</code></pre> |
| 972 | </div></div> |
| 973 | <div class="paragraph"><p>The output of ls-refs is as follows:</p></div> |
| 974 | <div class="literalblock"> |
| 975 | <div class="content"> |
| 976 | <pre><code>output = *ref |
| 977 | flush-pkt |
| 978 | ref = PKT-LINE(obj-id SP refname *(SP ref-attribute) LF) |
| 979 | ref-attribute = (symref | peeled) |
| 980 | symref = "symref-target:" symref-target |
| 981 | peeled = "peeled:" obj-id</code></pre> |
| 982 | </div></div> |
| 983 | </div> |
| 984 | <div class="sect2"> |
| 985 | <h3 id="_fetch"> fetch</h3> |
| 986 | <div class="paragraph"><p><code>fetch</code> is the command used to fetch a packfile in v2. It can be looked |
| 987 | at as a modified version of the v1 fetch where the ref-advertisement is |
| 988 | stripped out (since the <code>ls-refs</code> command fills that role) and the |
| 989 | message format is tweaked to eliminate redundancies and permit easy |
| 990 | addition of future extensions.</p></div> |
| 991 | <div class="paragraph"><p>Additional features not supported in the base command will be advertised |
| 992 | as the value of the command in the capability advertisement in the form |
| 993 | of a space separated list of features: "<command>=<feature 1> <feature 2>"</p></div> |
| 994 | <div class="paragraph"><p>A <code>fetch</code> request can take the following arguments:</p></div> |
| 995 | <div class="literalblock"> |
| 996 | <div class="content"> |
| 997 | <pre><code>want <oid> |
| 998 | Indicates to the server an object which the client wants to |
| 999 | retrieve. Wants can be anything and are not limited to |
| 1000 | advertised objects.</code></pre> |
| 1001 | </div></div> |
| 1002 | <div class="literalblock"> |
| 1003 | <div class="content"> |
| 1004 | <pre><code>have <oid> |
| 1005 | Indicates to the server an object which the client has locally. |
| 1006 | This allows the server to make a packfile which only contains |
| 1007 | the objects that the client needs. Multiple 'have' lines can be |
| 1008 | supplied.</code></pre> |
| 1009 | </div></div> |
| 1010 | <div class="literalblock"> |
| 1011 | <div class="content"> |
| 1012 | <pre><code>done |
| 1013 | Indicates to the server that negotiation should terminate (or |
| 1014 | not even begin if performing a clone) and that the server should |
| 1015 | use the information supplied in the request to construct the |
| 1016 | packfile.</code></pre> |
| 1017 | </div></div> |
| 1018 | <div class="literalblock"> |
| 1019 | <div class="content"> |
| 1020 | <pre><code>thin-pack |
| 1021 | Request that a thin pack be sent, which is a pack with deltas |
| 1022 | which reference base objects not contained within the pack (but |
| 1023 | are known to exist at the receiving end). This can reduce the |
| 1024 | network traffic significantly, but it requires the receiving end |
| 1025 | to know how to "thicken" these packs by adding the missing bases |
| 1026 | to the pack.</code></pre> |
| 1027 | </div></div> |
| 1028 | <div class="literalblock"> |
| 1029 | <div class="content"> |
| 1030 | <pre><code>no-progress |
| 1031 | Request that progress information that would normally be sent on |
| 1032 | side-band channel 2, during the packfile transfer, should not be |
| 1033 | sent. However, the side-band channel 3 is still used for error |
| 1034 | responses.</code></pre> |
| 1035 | </div></div> |
| 1036 | <div class="literalblock"> |
| 1037 | <div class="content"> |
| 1038 | <pre><code>include-tag |
| 1039 | Request that annotated tags should be sent if the objects they |
| 1040 | point to are being sent.</code></pre> |
| 1041 | </div></div> |
| 1042 | <div class="literalblock"> |
| 1043 | <div class="content"> |
| 1044 | <pre><code>ofs-delta |
| 1045 | Indicate that the client understands PACKv2 with delta referring |
| 1046 | to its base by position in pack rather than by an oid. That is, |
| 1047 | they can read OBJ_OFS_DELTA (ake type 6) in a packfile.</code></pre> |
| 1048 | </div></div> |
| 1049 | <div class="paragraph"><p>If the <em>shallow</em> feature is advertised the following arguments can be |
| 1050 | included in the clients request as well as the potential addition of the |
| 1051 | <em>shallow-info</em> section in the server’s response as explained below.</p></div> |
| 1052 | <div class="literalblock"> |
| 1053 | <div class="content"> |
| 1054 | <pre><code>shallow <oid> |
| 1055 | A client must notify the server of all commits for which it only |
| 1056 | has shallow copies (meaning that it doesn't have the parents of |
| 1057 | a commit) by supplying a 'shallow <oid>' line for each such |
| 1058 | object so that the server is aware of the limitations of the |
| 1059 | client's history. This is so that the server is aware that the |
| 1060 | client may not have all objects reachable from such commits.</code></pre> |
| 1061 | </div></div> |
| 1062 | <div class="literalblock"> |
| 1063 | <div class="content"> |
| 1064 | <pre><code>deepen <depth> |
| 1065 | Requests that the fetch/clone should be shallow having a commit |
| 1066 | depth of <depth> relative to the remote side.</code></pre> |
| 1067 | </div></div> |
| 1068 | <div class="literalblock"> |
| 1069 | <div class="content"> |
| 1070 | <pre><code>deepen-relative |
| 1071 | Requests that the semantics of the "deepen" command be changed |
| 1072 | to indicate that the depth requested is relative to the client's |
| 1073 | current shallow boundary, instead of relative to the requested |
| 1074 | commits.</code></pre> |
| 1075 | </div></div> |
| 1076 | <div class="literalblock"> |
| 1077 | <div class="content"> |
| 1078 | <pre><code>deepen-since <timestamp> |
| 1079 | Requests that the shallow clone/fetch should be cut at a |
| 1080 | specific time, instead of depth. Internally it's equivalent to |
| 1081 | doing "git rev-list --max-age=<timestamp>". Cannot be used with |
| 1082 | "deepen".</code></pre> |
| 1083 | </div></div> |
| 1084 | <div class="literalblock"> |
| 1085 | <div class="content"> |
| 1086 | <pre><code>deepen-not <rev> |
| 1087 | Requests that the shallow clone/fetch should be cut at a |
| 1088 | specific revision specified by '<rev>', instead of a depth. |
| 1089 | Internally it's equivalent of doing "git rev-list --not <rev>". |
| 1090 | Cannot be used with "deepen", but can be used with |
| 1091 | "deepen-since".</code></pre> |
| 1092 | </div></div> |
| Junio C Hamano | 309465b | 2018-05-30 06:32:59 | [diff] [blame^] | 1093 | <div class="paragraph"><p>If the <em>filter</em> feature is advertised, the following argument can be |
| 1094 | included in the client’s request:</p></div> |
| 1095 | <div class="literalblock"> |
| 1096 | <div class="content"> |
| 1097 | <pre><code>filter <filter-spec> |
| 1098 | Request that various objects from the packfile be omitted |
| 1099 | using one of several filtering techniques. These are intended |
| 1100 | for use with partial clone and partial fetch operations. See |
| 1101 | `rev-list` for possible "filter-spec" values.</code></pre> |
| 1102 | </div></div> |
| Junio C Hamano | ccb8252 | 2018-05-08 07:52:09 | [diff] [blame] | 1103 | <div class="paragraph"><p>The response of <code>fetch</code> is broken into a number of sections separated by |
| 1104 | delimiter packets (0001), with each section beginning with its section |
| 1105 | header.</p></div> |
| 1106 | <div class="literalblock"> |
| 1107 | <div class="content"> |
| 1108 | <pre><code>output = *section |
| 1109 | section = (acknowledgments | shallow-info | packfile) |
| 1110 | (flush-pkt | delim-pkt)</code></pre> |
| 1111 | </div></div> |
| 1112 | <div class="literalblock"> |
| 1113 | <div class="content"> |
| 1114 | <pre><code>acknowledgments = PKT-LINE("acknowledgments" LF) |
| 1115 | (nak | *ack) |
| 1116 | (ready) |
| 1117 | ready = PKT-LINE("ready" LF) |
| 1118 | nak = PKT-LINE("NAK" LF) |
| 1119 | ack = PKT-LINE("ACK" SP obj-id LF)</code></pre> |
| 1120 | </div></div> |
| 1121 | <div class="literalblock"> |
| 1122 | <div class="content"> |
| 1123 | <pre><code>shallow-info = PKT-LINE("shallow-info" LF) |
| 1124 | *PKT-LINE((shallow | unshallow) LF) |
| 1125 | shallow = "shallow" SP obj-id |
| 1126 | unshallow = "unshallow" SP obj-id</code></pre> |
| 1127 | </div></div> |
| 1128 | <div class="literalblock"> |
| 1129 | <div class="content"> |
| 1130 | <pre><code>packfile = PKT-LINE("packfile" LF) |
| 1131 | *PKT-LINE(%x01-03 *%x00-ff)</code></pre> |
| 1132 | </div></div> |
| 1133 | <div class="literalblock"> |
| 1134 | <div class="content"> |
| 1135 | <pre><code>acknowledgments section |
| 1136 | * If the client determines that it is finished with negotiations |
| 1137 | by sending a "done" line, the acknowledgments sections MUST be |
| 1138 | omitted from the server's response.</code></pre> |
| 1139 | </div></div> |
| 1140 | <div class="ulist"><ul> |
| 1141 | <li> |
| 1142 | <p> |
| 1143 | Always begins with the section header "acknowledgments" |
| 1144 | </p> |
| 1145 | </li> |
| 1146 | <li> |
| 1147 | <p> |
| 1148 | The server will respond with "NAK" if none of the object ids sent |
| 1149 | as have lines were common. |
| 1150 | </p> |
| 1151 | </li> |
| 1152 | <li> |
| 1153 | <p> |
| 1154 | The server will respond with "ACK obj-id" for all of the |
| 1155 | object ids sent as have lines which are common. |
| 1156 | </p> |
| 1157 | </li> |
| 1158 | <li> |
| 1159 | <p> |
| 1160 | A response cannot have both "ACK" lines as well as a "NAK" |
| 1161 | line. |
| 1162 | </p> |
| 1163 | </li> |
| 1164 | <li> |
| 1165 | <p> |
| 1166 | The server will respond with a "ready" line indicating that |
| 1167 | the server has found an acceptable common base and is ready to |
| 1168 | make and send a packfile (which will be found in the packfile |
| 1169 | section of the same response) |
| 1170 | </p> |
| 1171 | </li> |
| 1172 | <li> |
| 1173 | <p> |
| 1174 | If the server has found a suitable cut point and has decided |
| 1175 | to send a "ready" line, then the server can decide to (as an |
| 1176 | optimization) omit any "ACK" lines it would have sent during |
| 1177 | its response. This is because the server will have already |
| 1178 | determined the objects it plans to send to the client and no |
| 1179 | further negotiation is needed. |
| 1180 | </p> |
| 1181 | <div class="literalblock"> |
| 1182 | <div class="content"> |
| 1183 | <pre><code>shallow-info section |
| 1184 | * If the client has requested a shallow fetch/clone, a shallow |
| 1185 | client requests a fetch or the server is shallow then the |
| 1186 | server's response may include a shallow-info section. The |
| 1187 | shallow-info section will be included if (due to one of the |
| 1188 | above conditions) the server needs to inform the client of any |
| 1189 | shallow boundaries or adjustments to the clients already |
| 1190 | existing shallow boundaries.</code></pre> |
| 1191 | </div></div> |
| 1192 | </li> |
| 1193 | <li> |
| 1194 | <p> |
| 1195 | Always begins with the section header "shallow-info" |
| 1196 | </p> |
| 1197 | </li> |
| 1198 | <li> |
| 1199 | <p> |
| 1200 | If a positive depth is requested, the server will compute the |
| 1201 | set of commits which are no deeper than the desired depth. |
| 1202 | </p> |
| 1203 | </li> |
| 1204 | <li> |
| 1205 | <p> |
| 1206 | The server sends a "shallow obj-id" line for each commit whose |
| 1207 | parents will not be sent in the following packfile. |
| 1208 | </p> |
| 1209 | </li> |
| 1210 | <li> |
| 1211 | <p> |
| 1212 | The server sends an "unshallow obj-id" line for each commit |
| 1213 | which the client has indicated is shallow, but is no longer |
| 1214 | shallow as a result of the fetch (due to its parents being |
| 1215 | sent in the following packfile). |
| 1216 | </p> |
| 1217 | </li> |
| 1218 | <li> |
| 1219 | <p> |
| 1220 | The server MUST NOT send any "unshallow" lines for anything |
| 1221 | which the client has not indicated was shallow as a part of |
| 1222 | its request. |
| 1223 | </p> |
| 1224 | </li> |
| 1225 | <li> |
| 1226 | <p> |
| 1227 | This section is only included if a packfile section is also |
| 1228 | included in the response. |
| 1229 | </p> |
| 1230 | <div class="literalblock"> |
| 1231 | <div class="content"> |
| 1232 | <pre><code>packfile section |
| 1233 | * This section is only included if the client has sent 'want' |
| 1234 | lines in its request and either requested that no more |
| 1235 | negotiation be done by sending 'done' or if the server has |
| 1236 | decided it has found a sufficient cut point to produce a |
| 1237 | packfile.</code></pre> |
| 1238 | </div></div> |
| 1239 | </li> |
| 1240 | <li> |
| 1241 | <p> |
| 1242 | Always begins with the section header "packfile" |
| 1243 | </p> |
| 1244 | </li> |
| 1245 | <li> |
| 1246 | <p> |
| 1247 | The transmission of the packfile begins immediately after the |
| 1248 | section header |
| 1249 | </p> |
| 1250 | </li> |
| 1251 | <li> |
| 1252 | <p> |
| 1253 | The data transfer of the packfile is always multiplexed, using |
| 1254 | the same semantics of the <em>side-band-64k</em> capability from |
| 1255 | protocol version 1. This means that each packet, during the |
| 1256 | packfile data stream, is made up of a leading 4-byte pkt-line |
| 1257 | length (typical of the pkt-line format), followed by a 1-byte |
| 1258 | stream code, followed by the actual data. |
| 1259 | </p> |
| 1260 | <div class="literalblock"> |
| 1261 | <div class="content"> |
| 1262 | <pre><code>The stream code can be one of: |
| 1263 | 1 - pack data |
| 1264 | 2 - progress messages |
| 1265 | 3 - fatal error message just before stream aborts</code></pre> |
| 1266 | </div></div> |
| 1267 | </li> |
| 1268 | </ul></div> |
| 1269 | </div> |
| Junio C Hamano | b9d9d90 | 2018-05-23 07:07:42 | [diff] [blame] | 1270 | <div class="sect2"> |
| 1271 | <h3 id="_server_option"> server-option</h3> |
| 1272 | <div class="paragraph"><p>If advertised, indicates that any number of server specific options can be |
| 1273 | included in a request. This is done by sending each option as a |
| 1274 | "server-option=<option>" capability line in the capability-list section of |
| 1275 | a request.</p></div> |
| 1276 | <div class="paragraph"><p>The provided options must not contain a NUL or LF character.</p></div> |
| 1277 | </div> |
| Junio C Hamano | ccb8252 | 2018-05-08 07:52:09 | [diff] [blame] | 1278 | </div> |
| 1279 | </div> |
| 1280 | </div> |
| 1281 | <div id="footnotes"><hr /></div> |
| 1282 | <div id="footer"> |
| 1283 | <div id="footer-text"> |
| 1284 | Last updated |
| Junio C Hamano | 309465b | 2018-05-30 06:32:59 | [diff] [blame^] | 1285 | 2018-05-30 15:32:39 JST |
| Junio C Hamano | ccb8252 | 2018-05-08 07:52:09 | [diff] [blame] | 1286 | </div> |
| 1287 | </div> |
| 1288 | </body> |
| 1289 | </html> |
