Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1 | <!DOCTYPE html> |
| 2 | <html xmlns="http://www.w3.org/1999/xhtml" lang="en"> |
| 3 | <head> |
| 4 | <meta charset="UTF-8"/> |
| 5 | <meta http-equiv="X-UA-Compatible" content="IE=edge"/> |
| 6 | <meta name="viewport" content="width=device-width, initial-scale=1.0"/> |
| 7 | <meta name="generator" content="Asciidoctor 2.0.20"/> |
| 8 | <title>gitprotocol-v2(5)</title> |
| 9 | <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"/> |
| 10 | <style> |
| 11 | /*! Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */ |
| 12 | /* Uncomment the following line when using as a custom stylesheet */ |
| 13 | /* @import "https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"; */ |
| 14 | html{font-family:sans-serif;-webkit-text-size-adjust:100%} |
| 15 | a{background:none} |
| 16 | a:focus{outline:thin dotted} |
| 17 | a:active,a:hover{outline:0} |
| 18 | h1{font-size:2em;margin:.67em 0} |
| 19 | b,strong{font-weight:bold} |
| 20 | abbr{font-size:.9em} |
| 21 | abbr[title]{cursor:help;border-bottom:1px dotted #dddddf;text-decoration:none} |
| 22 | dfn{font-style:italic} |
| 23 | hr{height:0} |
| 24 | mark{background:#ff0;color:#000} |
| 25 | code,kbd,pre,samp{font-family:monospace;font-size:1em} |
| 26 | pre{white-space:pre-wrap} |
| 27 | q{quotes:"\201C" "\201D" "\2018" "\2019"} |
| 28 | small{font-size:80%} |
| 29 | sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline} |
| 30 | sup{top:-.5em} |
| 31 | sub{bottom:-.25em} |
| 32 | img{border:0} |
| 33 | svg:not(:root){overflow:hidden} |
| 34 | figure{margin:0} |
| 35 | audio,video{display:inline-block} |
| 36 | audio:not([controls]){display:none;height:0} |
| 37 | fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em} |
| 38 | legend{border:0;padding:0} |
| 39 | button,input,select,textarea{font-family:inherit;font-size:100%;margin:0} |
| 40 | button,input{line-height:normal} |
| 41 | button,select{text-transform:none} |
| 42 | button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer} |
| 43 | button[disabled],html input[disabled]{cursor:default} |
| 44 | input[type=checkbox],input[type=radio]{padding:0} |
| 45 | button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0} |
| 46 | textarea{overflow:auto;vertical-align:top} |
| 47 | table{border-collapse:collapse;border-spacing:0} |
| 48 | *,::before,::after{box-sizing:border-box} |
| 49 | html,body{font-size:100%} |
| 50 | body{background:#fff;color:rgba(0,0,0,.8);padding:0;margin:0;font-family:"Noto Serif","DejaVu Serif",serif;line-height:1;position:relative;cursor:auto;-moz-tab-size:4;-o-tab-size:4;tab-size:4;word-wrap:anywhere;-moz-osx-font-smoothing:grayscale;-webkit-font-smoothing:antialiased} |
| 51 | a:hover{cursor:pointer} |
| 52 | img,object,embed{max-width:100%;height:auto} |
| 53 | object,embed{height:100%} |
| 54 | img{-ms-interpolation-mode:bicubic} |
| 55 | .left{float:left!important} |
| 56 | .right{float:right!important} |
| 57 | .text-left{text-align:left!important} |
| 58 | .text-right{text-align:right!important} |
| 59 | .text-center{text-align:center!important} |
| 60 | .text-justify{text-align:justify!important} |
| 61 | .hide{display:none} |
| 62 | img,object,svg{display:inline-block;vertical-align:middle} |
| 63 | textarea{height:auto;min-height:50px} |
| 64 | select{width:100%} |
| 65 | .subheader,.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{line-height:1.45;color:#7a2518;font-weight:400;margin-top:0;margin-bottom:.25em} |
| 66 | div,dl,dt,dd,ul,ol,li,h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0} |
| 67 | a{color:#2156a5;text-decoration:underline;line-height:inherit} |
| 68 | a:hover,a:focus{color:#1d4b8f} |
| 69 | a img{border:0} |
| 70 | p{line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility} |
| 71 | p aside{font-size:.875em;line-height:1.35;font-style:italic} |
| 72 | h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{font-family:"Open Sans","DejaVu Sans",sans-serif;font-weight:300;font-style:normal;color:#ba3925;text-rendering:optimizeLegibility;margin-top:1em;margin-bottom:.5em;line-height:1.0125em} |
| 73 | h1 small,h2 small,h3 small,#toctitle small,.sidebarblock>.content>.title small,h4 small,h5 small,h6 small{font-size:60%;color:#e99b8f;line-height:0} |
| 74 | h1{font-size:2.125em} |
| 75 | h2{font-size:1.6875em} |
| 76 | h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em} |
| 77 | h4,h5{font-size:1.125em} |
| 78 | h6{font-size:1em} |
| 79 | hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em} |
| 80 | em,i{font-style:italic;line-height:inherit} |
| 81 | strong,b{font-weight:bold;line-height:inherit} |
| 82 | small{font-size:60%;line-height:inherit} |
| 83 | code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)} |
| 84 | ul,ol,dl{line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit} |
| 85 | ul,ol{margin-left:1.5em} |
| 86 | ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0} |
| 87 | ul.circle{list-style-type:circle} |
| 88 | ul.disc{list-style-type:disc} |
| 89 | ul.square{list-style-type:square} |
| 90 | ul.circle ul:not([class]),ul.disc ul:not([class]),ul.square ul:not([class]){list-style:inherit} |
| 91 | ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0} |
| 92 | dl dt{margin-bottom:.3125em;font-weight:bold} |
| 93 | dl dd{margin-bottom:1.25em} |
| 94 | blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd} |
| 95 | blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)} |
| 96 | @media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2} |
| 97 | h1{font-size:2.75em} |
| 98 | h2{font-size:2.3125em} |
| 99 | h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em} |
| 100 | h4{font-size:1.4375em}} |
| 101 | table{background:#fff;margin-bottom:1.25em;border:1px solid #dedede;word-wrap:normal} |
| 102 | table thead,table tfoot{background:#f7f8f7} |
| 103 | table thead tr th,table thead tr td,table tfoot tr th,table tfoot tr td{padding:.5em .625em .625em;font-size:inherit;color:rgba(0,0,0,.8);text-align:left} |
| 104 | table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)} |
| 105 | table tr.even,table tr.alt{background:#f8f8f7} |
| 106 | table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{line-height:1.6} |
| 107 | h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em} |
| 108 | h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400} |
| 109 | .center{margin-left:auto;margin-right:auto} |
| 110 | .stretch{width:100%} |
| 111 | .clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table} |
| 112 | .clearfix::after,.float-group::after{clear:both} |
| 113 | :not(pre).nobreak{word-wrap:normal} |
| 114 | :not(pre).nowrap{white-space:nowrap} |
| 115 | :not(pre).pre-wrap{white-space:pre-wrap} |
| 116 | :not(pre):not([class^=L])>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background:#f7f7f8;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed} |
| 117 | pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed} |
| 118 | pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit} |
| 119 | pre>code{display:block} |
| 120 | pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal} |
| 121 | em em{font-style:normal} |
| 122 | strong strong{font-weight:400} |
| 123 | .keyseq{color:rgba(51,51,51,.8)} |
| 124 | kbd{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;display:inline-block;color:rgba(0,0,0,.8);font-size:.65em;line-height:1.45;background:#f7f7f7;border:1px solid #ccc;border-radius:3px;box-shadow:0 1px 0 rgba(0,0,0,.2),inset 0 0 0 .1em #fff;margin:0 .15em;padding:.2em .5em;vertical-align:middle;position:relative;top:-.1em;white-space:nowrap} |
| 125 | .keyseq kbd:first-child{margin-left:0} |
| 126 | .keyseq kbd:last-child{margin-right:0} |
| 127 | .menuseq,.menuref{color:#000} |
| 128 | .menuseq b:not(.caret),.menuref{font-weight:inherit} |
| 129 | .menuseq{word-spacing:-.02em} |
| 130 | .menuseq b.caret{font-size:1.25em;line-height:.8} |
| 131 | .menuseq i.caret{font-weight:bold;text-align:center;width:.45em} |
| 132 | b.button::before,b.button::after{position:relative;top:-1px;font-weight:400} |
| 133 | b.button::before{content:"[";padding:0 3px 0 2px} |
| 134 | b.button::after{content:"]";padding:0 2px 0 3px} |
| 135 | p a>code:hover{color:rgba(0,0,0,.9)} |
| 136 | #header,#content,#footnotes,#footer{width:100%;margin:0 auto;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em} |
| 137 | #header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table} |
| 138 | #header::after,#content::after,#footnotes::after,#footer::after{clear:both} |
| 139 | #content{margin-top:1.25em} |
| 140 | #content::before{content:none} |
| 141 | #header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0} |
| 142 | #header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf} |
| 143 | #header>h1:only-child,body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px} |
| 144 | #header .details{border-bottom:1px solid #dddddf;line-height:1.45;padding-top:.25em;padding-bottom:.25em;padding-left:.25em;color:rgba(0,0,0,.6);display:flex;flex-flow:row wrap} |
| 145 | #header .details span:first-child{margin-left:-.125em} |
| 146 | #header .details span.email a{color:rgba(0,0,0,.85)} |
| 147 | #header .details br{display:none} |
| 148 | #header .details br+span::before{content:"\00a0\2013\00a0"} |
| 149 | #header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)} |
| 150 | #header .details br+span#revremark::before{content:"\00a0|\00a0"} |
| 151 | #header #revnumber{text-transform:capitalize} |
| 152 | #header #revnumber::after{content:"\00a0"} |
| 153 | #content>h1:first-child:not([class]){color:rgba(0,0,0,.85);border-bottom:1px solid #dddddf;padding-bottom:8px;margin-top:0;padding-top:1rem;margin-bottom:1.25rem} |
| 154 | #toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em} |
| 155 | #toc>ul{margin-left:.125em} |
| 156 | #toc ul.sectlevel0>li>a{font-style:italic} |
| 157 | #toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0} |
| 158 | #toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none} |
| 159 | #toc li{line-height:1.3334;margin-top:.3334em} |
| 160 | #toc a{text-decoration:none} |
| 161 | #toc a:active{text-decoration:underline} |
| 162 | #toctitle{color:#7a2518;font-size:1.2em} |
| 163 | @media screen and (min-width:768px){#toctitle{font-size:1.375em} |
| 164 | body.toc2{padding-left:15em;padding-right:0} |
| 165 | #toc.toc2{margin-top:0!important;background:#f8f8f7;position:fixed;width:15em;left:0;top:0;border-right:1px solid #e7e7e9;border-top-width:0!important;border-bottom-width:0!important;z-index:1000;padding:1.25em 1em;height:100%;overflow:auto} |
| 166 | #toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em} |
| 167 | #toc.toc2>ul{font-size:.9em;margin-bottom:0} |
| 168 | #toc.toc2 ul ul{margin-left:0;padding-left:1em} |
| 169 | #toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em} |
| 170 | body.toc2.toc-right{padding-left:0;padding-right:15em} |
| 171 | body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}} |
| 172 | @media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0} |
| 173 | #toc.toc2{width:20em} |
| 174 | #toc.toc2 #toctitle{font-size:1.375em} |
| 175 | #toc.toc2>ul{font-size:.95em} |
| 176 | #toc.toc2 ul ul{padding-left:1.25em} |
| 177 | body.toc2.toc-right{padding-left:0;padding-right:20em}} |
| 178 | #content #toc{border:1px solid #e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;border-radius:4px} |
| 179 | #content #toc>:first-child{margin-top:0} |
| 180 | #content #toc>:last-child{margin-bottom:0} |
| 181 | #footer{max-width:none;background:rgba(0,0,0,.8);padding:1.25em} |
| 182 | #footer-text{color:hsla(0,0%,100%,.8);line-height:1.44} |
| 183 | #content{margin-bottom:.625em} |
| 184 | .sect1{padding-bottom:.625em} |
| 185 | @media screen and (min-width:768px){#content{margin-bottom:1.25em} |
| 186 | .sect1{padding-bottom:1.25em}} |
| 187 | .sect1:last-child{padding-bottom:0} |
| 188 | .sect1+.sect1{border-top:1px solid #e7e7e9} |
| 189 | #content h1>a.anchor,h2>a.anchor,h3>a.anchor,#toctitle>a.anchor,.sidebarblock>.content>.title>a.anchor,h4>a.anchor,h5>a.anchor,h6>a.anchor{position:absolute;z-index:1001;width:1.5ex;margin-left:-1.5ex;display:block;text-decoration:none!important;visibility:hidden;text-align:center;font-weight:400} |
| 190 | #content h1>a.anchor::before,h2>a.anchor::before,h3>a.anchor::before,#toctitle>a.anchor::before,.sidebarblock>.content>.title>a.anchor::before,h4>a.anchor::before,h5>a.anchor::before,h6>a.anchor::before{content:"\00A7";font-size:.85em;display:block;padding-top:.1em} |
| 191 | #content h1:hover>a.anchor,#content h1>a.anchor:hover,h2:hover>a.anchor,h2>a.anchor:hover,h3:hover>a.anchor,#toctitle:hover>a.anchor,.sidebarblock>.content>.title:hover>a.anchor,h3>a.anchor:hover,#toctitle>a.anchor:hover,.sidebarblock>.content>.title>a.anchor:hover,h4:hover>a.anchor,h4>a.anchor:hover,h5:hover>a.anchor,h5>a.anchor:hover,h6:hover>a.anchor,h6>a.anchor:hover{visibility:visible} |
| 192 | #content h1>a.link,h2>a.link,h3>a.link,#toctitle>a.link,.sidebarblock>.content>.title>a.link,h4>a.link,h5>a.link,h6>a.link{color:#ba3925;text-decoration:none} |
| 193 | #content h1>a.link:hover,h2>a.link:hover,h3>a.link:hover,#toctitle>a.link:hover,.sidebarblock>.content>.title>a.link:hover,h4>a.link:hover,h5>a.link:hover,h6>a.link:hover{color:#a53221} |
| 194 | details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em} |
| 195 | details{margin-left:1.25rem} |
| 196 | details>summary{cursor:pointer;display:block;position:relative;line-height:1.6;margin-bottom:.625rem;outline:none;-webkit-tap-highlight-color:transparent} |
| 197 | details>summary::-webkit-details-marker{display:none} |
| 198 | details>summary::before{content:"";border:solid transparent;border-left:solid;border-width:.3em 0 .3em .5em;position:absolute;top:.5em;left:-1.25rem;transform:translateX(15%)} |
| 199 | details[open]>summary::before{border:solid transparent;border-top:solid;border-width:.5em .3em 0;transform:translateY(15%)} |
| 200 | details>summary::after{content:"";width:1.25rem;height:1em;position:absolute;top:.3em;left:-1.25rem} |
| 201 | .admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{text-rendering:optimizeLegibility;text-align:left;font-family:"Noto Serif","DejaVu Serif",serif;font-size:1rem;font-style:italic} |
| 202 | table.tableblock.fit-content>caption.title{white-space:nowrap;width:0} |
| 203 | .paragraph.lead>p,#preamble>.sectionbody>[class=paragraph]:first-of-type p{font-size:1.21875em;line-height:1.6;color:rgba(0,0,0,.85)} |
| 204 | .admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%} |
| 205 | .admonitionblock>table td.icon{text-align:center;width:80px} |
| 206 | .admonitionblock>table td.icon img{max-width:none} |
| 207 | .admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase} |
| 208 | .admonitionblock>table td.content{padding-left:1.125em;padding-right:1.25em;border-left:1px solid #dddddf;color:rgba(0,0,0,.6);word-wrap:anywhere} |
| 209 | .admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0} |
| 210 | .exampleblock>.content{border:1px solid #e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;border-radius:4px} |
| 211 | .sidebarblock{border:1px solid #dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;border-radius:4px} |
| 212 | .sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center} |
| 213 | .exampleblock>.content>:first-child,.sidebarblock>.content>:first-child{margin-top:0} |
| 214 | .exampleblock>.content>:last-child,.exampleblock>.content>:last-child>:last-child,.exampleblock>.content .olist>ol>li:last-child>:last-child,.exampleblock>.content .ulist>ul>li:last-child>:last-child,.exampleblock>.content .qlist>ol>li:last-child>:last-child,.sidebarblock>.content>:last-child,.sidebarblock>.content>:last-child>:last-child,.sidebarblock>.content .olist>ol>li:last-child>:last-child,.sidebarblock>.content .ulist>ul>li:last-child>:last-child,.sidebarblock>.content .qlist>ol>li:last-child>:last-child{margin-bottom:0} |
| 215 | .literalblock pre,.listingblock>.content>pre{border-radius:4px;overflow-x:auto;padding:1em;font-size:.8125em} |
| 216 | @media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}} |
| 217 | @media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}} |
| 218 | .literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class=highlight],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8} |
| 219 | .literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)} |
| 220 | .listingblock>.content{position:relative} |
| 221 | .listingblock code[data-lang]::before{display:none;content:attr(data-lang);position:absolute;font-size:.75em;top:.425rem;right:.5rem;line-height:1;text-transform:uppercase;color:inherit;opacity:.5} |
| 222 | .listingblock:hover code[data-lang]::before{display:block} |
| 223 | .listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5} |
| 224 | .listingblock.terminal pre .command:not([data-prompt])::before{content:"$"} |
| 225 | .listingblock pre.highlightjs{padding:0} |
| 226 | .listingblock pre.highlightjs>code{padding:1em;border-radius:4px} |
| 227 | .listingblock pre.prettyprint{border-width:0} |
| 228 | .prettyprint{background:#f7f7f8} |
| 229 | pre.prettyprint .linenums{line-height:1.45;margin-left:2em} |
| 230 | pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0} |
| 231 | pre.prettyprint li code[data-lang]::before{opacity:1} |
| 232 | pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none} |
| 233 | table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none} |
| 234 | table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal} |
| 235 | table.linenotable td.code{padding-left:.75em} |
| 236 | table.linenotable td.linenos,pre.pygments .linenos{border-right:1px solid;opacity:.35;padding-right:.5em;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none} |
| 237 | pre.pygments span.linenos{display:inline-block;margin-right:.75em} |
| 238 | .quoteblock{margin:0 1em 1.25em 1.5em;display:table} |
| 239 | .quoteblock:not(.excerpt)>.title{margin-left:-1.5em;margin-bottom:.75em} |
| 240 | .quoteblock blockquote,.quoteblock p{color:rgba(0,0,0,.85);font-size:1.15rem;line-height:1.75;word-spacing:.1em;letter-spacing:0;font-style:italic;text-align:justify} |
| 241 | .quoteblock blockquote{margin:0;padding:0;border:0} |
| 242 | .quoteblock blockquote::before{content:"\201c";float:left;font-size:2.75em;font-weight:bold;line-height:.6em;margin-left:-.6em;color:#7a2518;text-shadow:0 1px 2px rgba(0,0,0,.1)} |
| 243 | .quoteblock blockquote>.paragraph:last-child p{margin-bottom:0} |
| 244 | .quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right} |
| 245 | .verseblock{margin:0 1em 1.25em} |
| 246 | .verseblock pre{font-family:"Open Sans","DejaVu Sans",sans-serif;font-size:1.15rem;color:rgba(0,0,0,.85);font-weight:300;text-rendering:optimizeLegibility} |
| 247 | .verseblock pre strong{font-weight:400} |
| 248 | .verseblock .attribution{margin-top:1.25rem;margin-left:.5ex} |
| 249 | .quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic} |
| 250 | .quoteblock .attribution br,.verseblock .attribution br{display:none} |
| 251 | .quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)} |
| 252 | .quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none} |
| 253 | .quoteblock.abstract blockquote,.quoteblock.abstract p,.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{line-height:1.6;word-spacing:0} |
| 254 | .quoteblock.abstract{margin:0 1em 1.25em;display:block} |
| 255 | .quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center} |
| 256 | .quoteblock.excerpt>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf} |
| 257 | .quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0} |
| 258 | .quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem} |
| 259 | .quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;font-size:.85rem;text-align:left;margin-right:0} |
| 260 | p.tableblock:last-child{margin-bottom:0} |
| 261 | td.tableblock>.content{margin-bottom:1.25em;word-wrap:anywhere} |
| 262 | td.tableblock>.content>:last-child{margin-bottom:-1.25em} |
| 263 | table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede} |
| 264 | table.grid-all>*>tr>*{border-width:1px} |
| 265 | table.grid-cols>*>tr>*{border-width:0 1px} |
| 266 | table.grid-rows>*>tr>*{border-width:1px 0} |
| 267 | table.frame-all{border-width:1px} |
| 268 | table.frame-ends{border-width:1px 0} |
| 269 | table.frame-sides{border-width:0 1px} |
| 270 | table.frame-none>colgroup+*>:first-child>*,table.frame-sides>colgroup+*>:first-child>*{border-top-width:0} |
| 271 | table.frame-none>:last-child>:last-child>*,table.frame-sides>:last-child>:last-child>*{border-bottom-width:0} |
| 272 | table.frame-none>*>tr>:first-child,table.frame-ends>*>tr>:first-child{border-left-width:0} |
| 273 | table.frame-none>*>tr>:last-child,table.frame-ends>*>tr>:last-child{border-right-width:0} |
| 274 | table.stripes-all>*>tr,table.stripes-odd>*>tr:nth-of-type(odd),table.stripes-even>*>tr:nth-of-type(even),table.stripes-hover>*>tr:hover{background:#f8f8f7} |
| 275 | th.halign-left,td.halign-left{text-align:left} |
| 276 | th.halign-right,td.halign-right{text-align:right} |
| 277 | th.halign-center,td.halign-center{text-align:center} |
| 278 | th.valign-top,td.valign-top{vertical-align:top} |
| 279 | th.valign-bottom,td.valign-bottom{vertical-align:bottom} |
| 280 | th.valign-middle,td.valign-middle{vertical-align:middle} |
| 281 | table thead th,table tfoot th{font-weight:bold} |
| 282 | tbody tr th{background:#f7f8f7} |
| 283 | tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold} |
| 284 | p.tableblock>code:only-child{background:none;padding:0} |
| 285 | p.tableblock{font-size:1em} |
| 286 | ol{margin-left:1.75em} |
| 287 | ul li ol{margin-left:1.5em} |
| 288 | dl dd{margin-left:1.125em} |
| 289 | dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0} |
| 290 | li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em} |
| 291 | ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none} |
| 292 | ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em} |
| 293 | ul.unstyled,ol.unstyled{margin-left:0} |
| 294 | li>p:empty:only-child::before{content:"";display:inline-block} |
| 295 | ul.checklist>li>p:first-child{margin-left:-1em} |
| 296 | ul.checklist>li>p:first-child>.fa-square-o:first-child,ul.checklist>li>p:first-child>.fa-check-square-o:first-child{width:1.25em;font-size:.8em;position:relative;bottom:.125em} |
| 297 | ul.checklist>li>p:first-child>input[type=checkbox]:first-child{margin-right:.25em} |
| 298 | ul.inline{display:flex;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em} |
| 299 | ul.inline>li{margin-left:1.25em} |
| 300 | .unstyled dl dt{font-weight:400;font-style:normal} |
| 301 | ol.arabic{list-style-type:decimal} |
| 302 | ol.decimal{list-style-type:decimal-leading-zero} |
| 303 | ol.loweralpha{list-style-type:lower-alpha} |
| 304 | ol.upperalpha{list-style-type:upper-alpha} |
| 305 | ol.lowerroman{list-style-type:lower-roman} |
| 306 | ol.upperroman{list-style-type:upper-roman} |
| 307 | ol.lowergreek{list-style-type:lower-greek} |
| 308 | .hdlist>table,.colist>table{border:0;background:none} |
| 309 | .hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none} |
| 310 | td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em} |
| 311 | td.hdlist1{font-weight:bold;padding-bottom:1.25em} |
| 312 | td.hdlist2{word-wrap:anywhere} |
| 313 | .literalblock+.colist,.listingblock+.colist{margin-top:-.5em} |
| 314 | .colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top} |
| 315 | .colist td:not([class]):first-child img{max-width:none} |
| 316 | .colist td:not([class]):last-child{padding:.25em 0} |
| 317 | .thumb,.th{line-height:0;display:inline-block;border:4px solid #fff;box-shadow:0 0 0 1px #ddd} |
| 318 | .imageblock.left{margin:.25em .625em 1.25em 0} |
| 319 | .imageblock.right{margin:.25em 0 1.25em .625em} |
| 320 | .imageblock>.title{margin-bottom:0} |
| 321 | .imageblock.thumb,.imageblock.th{border-width:6px} |
| 322 | .imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em} |
| 323 | .image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0} |
| 324 | .image.left{margin-right:.625em} |
| 325 | .image.right{margin-left:.625em} |
| 326 | a.image{text-decoration:none;display:inline-block} |
| 327 | a.image object{pointer-events:none} |
| 328 | sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super} |
| 329 | sup.footnote a,sup.footnoteref a{text-decoration:none} |
| 330 | sup.footnote a:active,sup.footnoteref a:active{text-decoration:underline} |
| 331 | #footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em} |
| 332 | #footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0} |
| 333 | #footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em} |
| 334 | #footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em} |
| 335 | #footnotes .footnote:last-of-type{margin-bottom:0} |
| 336 | #content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0} |
| 337 | div.unbreakable{page-break-inside:avoid} |
| 338 | .big{font-size:larger} |
| 339 | .small{font-size:smaller} |
| 340 | .underline{text-decoration:underline} |
| 341 | .overline{text-decoration:overline} |
| 342 | .line-through{text-decoration:line-through} |
| 343 | .aqua{color:#00bfbf} |
| 344 | .aqua-background{background:#00fafa} |
| 345 | .black{color:#000} |
| 346 | .black-background{background:#000} |
| 347 | .blue{color:#0000bf} |
| 348 | .blue-background{background:#0000fa} |
| 349 | .fuchsia{color:#bf00bf} |
| 350 | .fuchsia-background{background:#fa00fa} |
| 351 | .gray{color:#606060} |
| 352 | .gray-background{background:#7d7d7d} |
| 353 | .green{color:#006000} |
| 354 | .green-background{background:#007d00} |
| 355 | .lime{color:#00bf00} |
| 356 | .lime-background{background:#00fa00} |
| 357 | .maroon{color:#600000} |
| 358 | .maroon-background{background:#7d0000} |
| 359 | .navy{color:#000060} |
| 360 | .navy-background{background:#00007d} |
| 361 | .olive{color:#606000} |
| 362 | .olive-background{background:#7d7d00} |
| 363 | .purple{color:#600060} |
| 364 | .purple-background{background:#7d007d} |
| 365 | .red{color:#bf0000} |
| 366 | .red-background{background:#fa0000} |
| 367 | .silver{color:#909090} |
| 368 | .silver-background{background:#bcbcbc} |
| 369 | .teal{color:#006060} |
| 370 | .teal-background{background:#007d7d} |
| 371 | .white{color:#bfbfbf} |
| 372 | .white-background{background:#fafafa} |
| 373 | .yellow{color:#bfbf00} |
| 374 | .yellow-background{background:#fafa00} |
| 375 | span.icon>.fa{cursor:default} |
| 376 | a span.icon>.fa{cursor:inherit} |
| 377 | .admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default} |
| 378 | .admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c} |
| 379 | .admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111} |
| 380 | .admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900} |
| 381 | .admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400} |
| 382 | .admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000} |
| 383 | .conum[data-value]{display:inline-block;color:#fff!important;background:rgba(0,0,0,.8);border-radius:50%;text-align:center;font-size:.75em;width:1.67em;height:1.67em;line-height:1.67em;font-family:"Open Sans","DejaVu Sans",sans-serif;font-style:normal;font-weight:bold} |
| 384 | .conum[data-value] *{color:#fff!important} |
| 385 | .conum[data-value]+b{display:none} |
| 386 | .conum[data-value]::after{content:attr(data-value)} |
| 387 | pre .conum[data-value]{position:relative;top:-.125em} |
| 388 | b.conum *{color:inherit!important} |
| 389 | .conum:not([data-value]):empty{display:none} |
| 390 | dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility} |
| 391 | h1,h2,p,td.content,span.alt,summary{letter-spacing:-.01em} |
| 392 | p strong,td.content strong,div.footnote strong{letter-spacing:-.005em} |
| 393 | p,blockquote,dt,td.content,td.hdlist1,span.alt,summary{font-size:1.0625rem} |
| 394 | p{margin-bottom:1.25rem} |
| 395 | .sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em} |
| 396 | .exampleblock>.content{background:#fffef7;border-color:#e0e0dc;box-shadow:0 1px 4px #e0e0dc} |
| 397 | .print-only{display:none!important} |
| 398 | @page{margin:1.25cm .75cm} |
| 399 | @media print{*{box-shadow:none!important;text-shadow:none!important} |
| 400 | html{font-size:80%} |
| 401 | a{color:inherit!important;text-decoration:underline!important} |
| 402 | a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important} |
| 403 | a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em} |
| 404 | abbr[title]{border-bottom:1px dotted} |
| 405 | abbr[title]::after{content:" (" attr(title) ")"} |
| 406 | pre,blockquote,tr,img,object,svg{page-break-inside:avoid} |
| 407 | thead{display:table-header-group} |
| 408 | svg{max-width:100%} |
| 409 | p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3} |
| 410 | h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid} |
| 411 | #header,#content,#footnotes,#footer{max-width:none} |
| 412 | #toc,.sidebarblock,.exampleblock>.content{background:none!important} |
| 413 | #toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important} |
| 414 | body.book #header{text-align:center} |
| 415 | body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em} |
| 416 | body.book #header .details{border:0!important;display:block;padding:0!important} |
| 417 | body.book #header .details span:first-child{margin-left:0!important} |
| 418 | body.book #header .details br{display:block} |
| 419 | body.book #header .details br+span::before{content:none!important} |
| 420 | body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important} |
| 421 | body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always} |
| 422 | .listingblock code[data-lang]::before{display:block} |
| 423 | #footer{padding:0 .9375em} |
| 424 | .hide-on-print{display:none!important} |
| 425 | .print-only{display:block!important} |
| 426 | .hide-for-print{display:none!important} |
| 427 | .show-for-print{display:inherit!important}} |
| 428 | @media amzn-kf8,print{#header>h1:first-child{margin-top:1.25rem} |
| 429 | .sect1{padding:0!important} |
| 430 | .sect1+.sect1{border:0} |
| 431 | #footer{background:none} |
| 432 | #footer-text{color:rgba(0,0,0,.6);font-size:.9em}} |
| 433 | @media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}} |
| 434 | </style> |
| 435 | <style> |
| 436 | pre>code { |
| 437 | display: inline; |
| 438 | } |
| 439 | </style> |
| 440 | </head> |
| 441 | <body class="manpage"> |
| 442 | <div id="header"> |
| 443 | <h1>gitprotocol-v2(5) Manual Page</h1> |
| 444 | <h2 id="_name">NAME</h2> |
| 445 | <div class="sectionbody"> |
| 446 | <p>gitprotocol-v2 - Git Wire Protocol, Version 2</p> |
| 447 | </div> |
| 448 | </div> |
| 449 | <div id="content"> |
| 450 | <div class="sect1"> |
| 451 | <h2 id="_synopsis">SYNOPSIS</h2> |
| 452 | <div class="sectionbody"> |
| 453 | <div class="verseblock"> |
| 454 | <pre class="content"><over-the-wire-protocol></pre> |
| 455 | </div> |
| 456 | </div> |
| 457 | </div> |
| 458 | <div class="sect1"> |
| 459 | <h2 id="_description">DESCRIPTION</h2> |
| 460 | <div class="sectionbody"> |
| 461 | <div class="paragraph"> |
| 462 | <p>This document presents a specification for a version 2 of Git’s wire |
| 463 | protocol. Protocol v2 will improve upon v1 in the following ways:</p> |
| 464 | </div> |
| 465 | <div class="ulist"> |
| 466 | <ul> |
| 467 | <li> |
| 468 | <p>Instead of multiple service names, multiple commands will be |
| 469 | supported by a single service</p> |
| 470 | </li> |
| 471 | <li> |
| 472 | <p>Easily extendable as capabilities are moved into their own section |
| 473 | of the protocol, no longer being hidden behind a NUL byte and |
| 474 | limited by the size of a pkt-line</p> |
| 475 | </li> |
| 476 | <li> |
| 477 | <p>Separate out other information hidden behind NUL bytes (e.g. agent |
| 478 | string as a capability and symrefs can be requested using <em>ls-refs</em>)</p> |
| 479 | </li> |
| 480 | <li> |
| 481 | <p>Reference advertisement will be omitted unless explicitly requested</p> |
| 482 | </li> |
| 483 | <li> |
| 484 | <p>ls-refs command to explicitly request some refs</p> |
| 485 | </li> |
| 486 | <li> |
| 487 | <p>Designed with http and stateless-rpc in mind. With clear flush |
| 488 | semantics the http remote helper can simply act as a proxy</p> |
| 489 | </li> |
| 490 | </ul> |
| 491 | </div> |
| 492 | <div class="paragraph"> |
| 493 | <p>In protocol v2 communication is command oriented. When first contacting a |
| 494 | server a list of capabilities will be advertised. Some of these capabilities |
| 495 | will be commands which a client can request be executed. Once a command |
| 496 | has completed, a client can reuse the connection and request that other |
| 497 | commands be executed.</p> |
| 498 | </div> |
| 499 | </div> |
| 500 | </div> |
| 501 | <div class="sect1"> |
| 502 | <h2 id="_packet_line_framing">Packet-Line Framing</h2> |
| 503 | <div class="sectionbody"> |
| 504 | <div class="paragraph"> |
| 505 | <p>All communication is done using packet-line framing, just as in v1. See |
| 506 | <a href="gitprotocol-pack.html">gitprotocol-pack(5)</a> and <a href="gitprotocol-common.html">gitprotocol-common(5)</a> for more information.</p> |
| 507 | </div> |
| 508 | <div class="paragraph"> |
| 509 | <p>In protocol v2 these special packets will have the following semantics:</p> |
| 510 | </div> |
| 511 | <div class="ulist"> |
| 512 | <ul> |
| 513 | <li> |
| 514 | <p><em>0000</em> Flush Packet (flush-pkt) - indicates the end of a message</p> |
| 515 | </li> |
| 516 | <li> |
| 517 | <p><em>0001</em> Delimiter Packet (delim-pkt) - separates sections of a message</p> |
| 518 | </li> |
| 519 | <li> |
| 520 | <p><em>0002</em> Response End Packet (response-end-pkt) - indicates the end of a |
| 521 | response for stateless connections</p> |
| 522 | </li> |
| 523 | </ul> |
| 524 | </div> |
| 525 | </div> |
| 526 | </div> |
| 527 | <div class="sect1"> |
| 528 | <h2 id="_initial_client_request">Initial Client Request</h2> |
| 529 | <div class="sectionbody"> |
| 530 | <div class="paragraph"> |
| 531 | <p>In general a client can request to speak protocol v2 by sending |
| 532 | <code>version=2</code> through the respective side-channel for the transport being |
| 533 | used which inevitably sets <code>GIT_PROTOCOL</code>. More information can be |
| 534 | found in <a href="gitprotocol-pack.html">gitprotocol-pack(5)</a> and <a href="gitprotocol-http.html">gitprotocol-http(5)</a>, as well as the |
| 535 | <code>GIT_PROTOCOL</code> definition in <code>git.txt</code>. In all cases the |
| 536 | response from the server is the capability advertisement.</p> |
| 537 | </div> |
| 538 | <div class="sect2"> |
| 539 | <h3 id="_git_transport">Git Transport</h3> |
| 540 | <div class="paragraph"> |
| 541 | <p>When using the git:// transport, you can request to use protocol v2 by |
| 542 | sending "version=2" as an extra parameter:</p> |
| 543 | </div> |
| 544 | <div class="literalblock"> |
| 545 | <div class="content"> |
| 546 | <pre>003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0</pre> |
| 547 | </div> |
| 548 | </div> |
| 549 | </div> |
| 550 | <div class="sect2"> |
| 551 | <h3 id="_ssh_and_file_transport">SSH and File Transport</h3> |
| 552 | <div class="paragraph"> |
| 553 | <p>When using either the ssh:// or file:// transport, the GIT_PROTOCOL |
| 554 | environment variable must be set explicitly to include "version=2". |
| 555 | The server may need to be configured to allow this environment variable |
| 556 | to pass.</p> |
| 557 | </div> |
| 558 | </div> |
| 559 | <div class="sect2"> |
| 560 | <h3 id="_http_transport">HTTP Transport</h3> |
| 561 | <div class="paragraph"> |
| 562 | <p>When using the http:// or https:// transport a client makes a "smart" |
| 563 | info/refs request as described in <a href="gitprotocol-http.html">gitprotocol-http(5)</a> and requests that |
| 564 | v2 be used by supplying "version=2" in the <code>Git-Protocol</code> header.</p> |
| 565 | </div> |
| 566 | <div class="literalblock"> |
| 567 | <div class="content"> |
| 568 | <pre>C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 |
| 569 | C: Git-Protocol: version=2</pre> |
| 570 | </div> |
| 571 | </div> |
| 572 | <div class="paragraph"> |
| 573 | <p>A v2 server would reply:</p> |
| 574 | </div> |
| 575 | <div class="literalblock"> |
| 576 | <div class="content"> |
| 577 | <pre>S: 200 OK |
| 578 | S: <Some headers> |
| 579 | S: ... |
| 580 | S: |
| 581 | S: 000eversion 2\n |
| 582 | S: <capability-advertisement></pre> |
| 583 | </div> |
| 584 | </div> |
| 585 | <div class="paragraph"> |
| 586 | <p>Subsequent requests are then made directly to the service |
| 587 | <code>$GIT_URL/git-upload-pack</code>. (This works the same for git-receive-pack).</p> |
| 588 | </div> |
| 589 | <div class="paragraph"> |
| 590 | <p>Uses the <code>--http-backend-info-refs</code> option to |
| 591 | <a href="git-upload-pack.html">git-upload-pack(1)</a>.</p> |
| 592 | </div> |
| 593 | <div class="paragraph"> |
| 594 | <p>The server may need to be configured to pass this header’s contents via |
| 595 | the <code>GIT_PROTOCOL</code> variable. See the discussion in <code>git-http-backend.txt</code>.</p> |
| 596 | </div> |
| 597 | </div> |
| 598 | </div> |
| 599 | </div> |
| 600 | <div class="sect1"> |
| 601 | <h2 id="_capability_advertisement">Capability Advertisement</h2> |
| 602 | <div class="sectionbody"> |
| 603 | <div class="paragraph"> |
| 604 | <p>A server which decides to communicate (based on a request from a client) |
| 605 | using protocol version 2, notifies the client by sending a version string |
| 606 | in its initial response followed by an advertisement of its capabilities. |
| 607 | Each capability is a key with an optional value. Clients must ignore all |
| 608 | unknown keys. Semantics of unknown values are left to the definition of |
| 609 | each key. Some capabilities will describe commands which can be requested |
| 610 | to be executed by the client.</p> |
| 611 | </div> |
| 612 | <div class="literalblock"> |
| 613 | <div class="content"> |
| 614 | <pre>capability-advertisement = protocol-version |
| 615 | capability-list |
| 616 | flush-pkt</pre> |
| 617 | </div> |
| 618 | </div> |
| 619 | <div class="literalblock"> |
| 620 | <div class="content"> |
| 621 | <pre>protocol-version = PKT-LINE("version 2" LF) |
| 622 | capability-list = *capability |
| 623 | capability = PKT-LINE(key[=value] LF)</pre> |
| 624 | </div> |
| 625 | </div> |
| 626 | <div class="literalblock"> |
| 627 | <div class="content"> |
| 628 | <pre>key = 1*(ALPHA | DIGIT | "-_") |
| 629 | value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")</pre> |
| 630 | </div> |
| 631 | </div> |
| 632 | </div> |
| 633 | </div> |
| 634 | <div class="sect1"> |
| 635 | <h2 id="_command_request">Command Request</h2> |
| 636 | <div class="sectionbody"> |
| 637 | <div class="paragraph"> |
| 638 | <p>After receiving the capability advertisement, a client can then issue a |
| 639 | request to select the command it wants with any particular capabilities |
| 640 | or arguments. There is then an optional section where the client can |
| 641 | provide any command specific parameters or queries. Only a single |
| 642 | command can be requested at a time.</p> |
| 643 | </div> |
| 644 | <div class="literalblock"> |
| 645 | <div class="content"> |
| 646 | <pre>request = empty-request | command-request |
| 647 | empty-request = flush-pkt |
| 648 | command-request = command |
| 649 | capability-list |
| 650 | delim-pkt |
| 651 | command-args |
| 652 | flush-pkt |
| 653 | command = PKT-LINE("command=" key LF) |
| 654 | command-args = *command-specific-arg</pre> |
| 655 | </div> |
| 656 | </div> |
| 657 | <div class="literalblock"> |
| 658 | <div class="content"> |
| 659 | <pre>command-specific-args are packet line framed arguments defined by |
| 660 | each individual command.</pre> |
| 661 | </div> |
| 662 | </div> |
| 663 | <div class="paragraph"> |
| 664 | <p>The server will then check to ensure that the client’s request is |
| 665 | comprised of a valid command as well as valid capabilities which were |
| 666 | advertised. If the request is valid the server will then execute the |
| 667 | command. A server MUST wait till it has received the client’s entire |
| 668 | request before issuing a response. The format of the response is |
| 669 | determined by the command being executed, but in all cases a flush-pkt |
| 670 | indicates the end of the response.</p> |
| 671 | </div> |
| 672 | <div class="paragraph"> |
| 673 | <p>When a command has finished, and the client has received the entire |
| 674 | response from the server, a client can either request that another |
| 675 | command be executed or can terminate the connection. A client may |
| 676 | optionally send an empty request consisting of just a flush-pkt to |
| 677 | indicate that no more requests will be made.</p> |
| 678 | </div> |
| 679 | </div> |
| 680 | </div> |
| 681 | <div class="sect1"> |
| 682 | <h2 id="_capabilities">Capabilities</h2> |
| 683 | <div class="sectionbody"> |
| 684 | <div class="paragraph"> |
| 685 | <p>There are two different types of capabilities: normal capabilities, |
| 686 | which can be used to convey information or alter the behavior of a |
| 687 | request, and commands, which are the core actions that a client wants to |
| 688 | perform (fetch, push, etc).</p> |
| 689 | </div> |
| 690 | <div class="paragraph"> |
| 691 | <p>Protocol version 2 is stateless by default. This means that all commands |
| 692 | must only last a single round and be stateless from the perspective of the |
| 693 | server side, unless the client has requested a capability indicating that |
| 694 | state should be maintained by the server. Clients MUST NOT require state |
| 695 | management on the server side in order to function correctly. This |
| 696 | permits simple round-robin load-balancing on the server side, without |
| 697 | needing to worry about state management.</p> |
| 698 | </div> |
| 699 | <div class="sect2"> |
| 700 | <h3 id="_agent">agent</h3> |
| 701 | <div class="paragraph"> |
| 702 | <p>The server can advertise the <code>agent</code> capability with a value <code>X</code> (in the |
| 703 | form <code>agent=X</code>) to notify the client that the server is running version |
| 704 | <code>X</code>. The client may optionally send its own agent string by including |
| 705 | the <code>agent</code> capability with a value <code>Y</code> (in the form <code>agent=Y</code>) in its |
| 706 | request to the server (but it MUST NOT do so if the server did not |
| 707 | advertise the agent capability). The <code>X</code> and <code>Y</code> strings may contain any |
| 708 | printable ASCII characters except space (i.e., the byte range 32 < x < |
| 709 | 127), and are typically of the form "package/version" (e.g., |
| 710 | "git/1.8.3.1"). The agent strings are purely informative for statistics |
| 711 | and debugging purposes, and MUST NOT be used to programmatically assume |
| 712 | the presence or absence of particular features.</p> |
| 713 | </div> |
| 714 | </div> |
| 715 | <div class="sect2"> |
| 716 | <h3 id="_ls_refs">ls-refs</h3> |
| 717 | <div class="paragraph"> |
| 718 | <p><code>ls-refs</code> is the command used to request a reference advertisement in v2. |
| 719 | Unlike the current reference advertisement, ls-refs takes in arguments |
| 720 | which can be used to limit the refs sent from the server.</p> |
| 721 | </div> |
| 722 | <div class="paragraph"> |
| 723 | <p>Additional features not supported in the base command will be advertised |
| 724 | as the value of the command in the capability advertisement in the form |
| 725 | of a space separated list of features: "<command>=<feature-1> <feature-2>"</p> |
| 726 | </div> |
| 727 | <div class="paragraph"> |
| 728 | <p>ls-refs takes in the following arguments:</p> |
| 729 | </div> |
| 730 | <div class="literalblock"> |
| 731 | <div class="content"> |
| 732 | <pre> symrefs |
| 733 | In addition to the object pointed by it, show the underlying ref |
| 734 | pointed by it when showing a symbolic ref. |
| 735 | peel |
| 736 | Show peeled tags. |
| 737 | ref-prefix <prefix> |
| 738 | When specified, only references having a prefix matching one of |
| 739 | the provided prefixes are displayed. Multiple instances may be |
| 740 | given, in which case references matching any prefix will be |
| 741 | shown. Note that this is purely for optimization; a server MAY |
| 742 | show refs not matching the prefix if it chooses, and clients |
| 743 | should filter the result themselves.</pre> |
| 744 | </div> |
| 745 | </div> |
| 746 | <div class="paragraph"> |
| 747 | <p>If the <em>unborn</em> feature is advertised the following argument can be |
| 748 | included in the client’s request.</p> |
| 749 | </div> |
| 750 | <div class="literalblock"> |
| 751 | <div class="content"> |
| 752 | <pre> unborn |
| 753 | The server will send information about HEAD even if it is a symref |
| 754 | pointing to an unborn branch in the form "unborn HEAD |
| 755 | symref-target:<target>".</pre> |
| 756 | </div> |
| 757 | </div> |
| 758 | <div class="paragraph"> |
| 759 | <p>The output of ls-refs is as follows:</p> |
| 760 | </div> |
| 761 | <div class="literalblock"> |
| 762 | <div class="content"> |
| 763 | <pre>output = *ref |
| 764 | flush-pkt |
| 765 | obj-id-or-unborn = (obj-id | "unborn") |
| 766 | ref = PKT-LINE(obj-id-or-unborn SP refname *(SP ref-attribute) LF) |
| 767 | ref-attribute = (symref | peeled) |
| 768 | symref = "symref-target:" symref-target |
| 769 | peeled = "peeled:" obj-id</pre> |
| 770 | </div> |
| 771 | </div> |
| 772 | </div> |
| 773 | <div class="sect2"> |
| 774 | <h3 id="_fetch">fetch</h3> |
| 775 | <div class="paragraph"> |
| 776 | <p><code>fetch</code> is the command used to fetch a packfile in v2. It can be looked |
| 777 | at as a modified version of the v1 fetch where the ref-advertisement is |
| 778 | stripped out (since the <code>ls-refs</code> command fills that role) and the |
| 779 | message format is tweaked to eliminate redundancies and permit easy |
| 780 | addition of future extensions.</p> |
| 781 | </div> |
| 782 | <div class="paragraph"> |
| 783 | <p>Additional features not supported in the base command will be advertised |
| 784 | as the value of the command in the capability advertisement in the form |
| 785 | of a space separated list of features: "<command>=<feature-1> <feature-2>"</p> |
| 786 | </div> |
| 787 | <div class="paragraph"> |
| 788 | <p>A <code>fetch</code> request can take the following arguments:</p> |
| 789 | </div> |
| 790 | <div class="literalblock"> |
| 791 | <div class="content"> |
| 792 | <pre> want <oid> |
| 793 | Indicates to the server an object which the client wants to |
| 794 | retrieve. Wants can be anything and are not limited to |
| 795 | advertised objects.</pre> |
| 796 | </div> |
| 797 | </div> |
| 798 | <div class="literalblock"> |
| 799 | <div class="content"> |
| 800 | <pre> have <oid> |
| 801 | Indicates to the server an object which the client has locally. |
| 802 | This allows the server to make a packfile which only contains |
| 803 | the objects that the client needs. Multiple 'have' lines can be |
| 804 | supplied.</pre> |
| 805 | </div> |
| 806 | </div> |
| 807 | <div class="literalblock"> |
| 808 | <div class="content"> |
| 809 | <pre> done |
| 810 | Indicates to the server that negotiation should terminate (or |
| 811 | not even begin if performing a clone) and that the server should |
| 812 | use the information supplied in the request to construct the |
| 813 | packfile.</pre> |
| 814 | </div> |
| 815 | </div> |
| 816 | <div class="literalblock"> |
| 817 | <div class="content"> |
| 818 | <pre> thin-pack |
| 819 | Request that a thin pack be sent, which is a pack with deltas |
| 820 | which reference base objects not contained within the pack (but |
| 821 | are known to exist at the receiving end). This can reduce the |
| 822 | network traffic significantly, but it requires the receiving end |
| 823 | to know how to "thicken" these packs by adding the missing bases |
| 824 | to the pack.</pre> |
| 825 | </div> |
| 826 | </div> |
| 827 | <div class="literalblock"> |
| 828 | <div class="content"> |
| 829 | <pre> no-progress |
| 830 | Request that progress information that would normally be sent on |
| 831 | side-band channel 2, during the packfile transfer, should not be |
| 832 | sent. However, the side-band channel 3 is still used for error |
| 833 | responses.</pre> |
| 834 | </div> |
| 835 | </div> |
| 836 | <div class="literalblock"> |
| 837 | <div class="content"> |
| 838 | <pre> include-tag |
| 839 | Request that annotated tags should be sent if the objects they |
| 840 | point to are being sent.</pre> |
| 841 | </div> |
| 842 | </div> |
| 843 | <div class="literalblock"> |
| 844 | <div class="content"> |
| 845 | <pre> ofs-delta |
| 846 | Indicate that the client understands PACKv2 with delta referring |
| 847 | to its base by position in pack rather than by an oid. That is, |
| 848 | they can read OBJ_OFS_DELTA (aka type 6) in a packfile.</pre> |
| 849 | </div> |
| 850 | </div> |
| 851 | <div class="paragraph"> |
| 852 | <p>If the <em>shallow</em> feature is advertised the following arguments can be |
| 853 | included in the clients request as well as the potential addition of the |
| 854 | <em>shallow-info</em> section in the server’s response as explained below.</p> |
| 855 | </div> |
| 856 | <div class="literalblock"> |
| 857 | <div class="content"> |
| 858 | <pre> shallow <oid> |
| 859 | A client must notify the server of all commits for which it only |
| 860 | has shallow copies (meaning that it doesn't have the parents of |
| 861 | a commit) by supplying a 'shallow <oid>' line for each such |
| 862 | object so that the server is aware of the limitations of the |
| 863 | client's history. This is so that the server is aware that the |
| 864 | client may not have all objects reachable from such commits.</pre> |
| 865 | </div> |
| 866 | </div> |
| 867 | <div class="literalblock"> |
| 868 | <div class="content"> |
| 869 | <pre> deepen <depth> |
| 870 | Requests that the fetch/clone should be shallow having a commit |
| 871 | depth of <depth> relative to the remote side.</pre> |
| 872 | </div> |
| 873 | </div> |
| 874 | <div class="literalblock"> |
| 875 | <div class="content"> |
| 876 | <pre> deepen-relative |
| 877 | Requests that the semantics of the "deepen" command be changed |
| 878 | to indicate that the depth requested is relative to the client's |
| 879 | current shallow boundary, instead of relative to the requested |
| 880 | commits.</pre> |
| 881 | </div> |
| 882 | </div> |
| 883 | <div class="literalblock"> |
| 884 | <div class="content"> |
| 885 | <pre> deepen-since <timestamp> |
| 886 | Requests that the shallow clone/fetch should be cut at a |
| 887 | specific time, instead of depth. Internally it's equivalent to |
| 888 | doing "git rev-list --max-age=<timestamp>". Cannot be used with |
| 889 | "deepen".</pre> |
| 890 | </div> |
| 891 | </div> |
| 892 | <div class="literalblock"> |
| 893 | <div class="content"> |
| 894 | <pre> deepen-not <rev> |
| 895 | Requests that the shallow clone/fetch should be cut at a |
| 896 | specific revision specified by '<rev>', instead of a depth. |
| 897 | Internally it's equivalent of doing "git rev-list --not <rev>". |
| 898 | Cannot be used with "deepen", but can be used with |
| 899 | "deepen-since".</pre> |
| 900 | </div> |
| 901 | </div> |
| 902 | <div class="paragraph"> |
| 903 | <p>If the <em>filter</em> feature is advertised, the following argument can be |
| 904 | included in the client’s request:</p> |
| 905 | </div> |
| 906 | <div class="literalblock"> |
| 907 | <div class="content"> |
| 908 | <pre> filter <filter-spec> |
| 909 | Request that various objects from the packfile be omitted |
| 910 | using one of several filtering techniques. These are intended |
| 911 | for use with partial clone and partial fetch operations. See |
| 912 | `rev-list` for possible "filter-spec" values. When communicating |
| 913 | with other processes, senders SHOULD translate scaled integers |
| 914 | (e.g. "1k") into a fully-expanded form (e.g. "1024") to aid |
| 915 | interoperability with older receivers that may not understand |
| 916 | newly-invented scaling suffixes. However, receivers SHOULD |
| 917 | accept the following suffixes: 'k', 'm', and 'g' for 1024, |
| 918 | 1048576, and 1073741824, respectively.</pre> |
| 919 | </div> |
| 920 | </div> |
| 921 | <div class="paragraph"> |
| 922 | <p>If the <em>ref-in-want</em> feature is advertised, the following argument can |
| 923 | be included in the client’s request as well as the potential addition of |
| 924 | the <em>wanted-refs</em> section in the server’s response as explained below.</p> |
| 925 | </div> |
| 926 | <div class="literalblock"> |
| 927 | <div class="content"> |
| 928 | <pre> want-ref <ref> |
| 929 | Indicates to the server that the client wants to retrieve a |
| 930 | particular ref, where <ref> is the full name of a ref on the |
| 931 | server. It is a protocol error to send want-ref for the |
| 932 | same ref more than once.</pre> |
| 933 | </div> |
| 934 | </div> |
| 935 | <div class="paragraph"> |
| 936 | <p>If the <em>sideband-all</em> feature is advertised, the following argument can be |
| 937 | included in the client’s request:</p> |
| 938 | </div> |
| 939 | <div class="literalblock"> |
| 940 | <div class="content"> |
| 941 | <pre> sideband-all |
| 942 | Instruct the server to send the whole response multiplexed, not just |
| 943 | the packfile section. All non-flush and non-delim PKT-LINE in the |
| 944 | response (not only in the packfile section) will then start with a byte |
| 945 | indicating its sideband (1, 2, or 3), and the server may send "0005\2" |
| 946 | (a PKT-LINE of sideband 2 with no payload) as a keepalive packet.</pre> |
| 947 | </div> |
| 948 | </div> |
| 949 | <div class="paragraph"> |
| 950 | <p>If the <em>packfile-uris</em> feature is advertised, the following argument |
| 951 | can be included in the client’s request as well as the potential |
| 952 | addition of the <em>packfile-uris</em> section in the server’s response as |
| 953 | explained below. Note that at most one <code>packfile-uris</code> line can be sent |
| 954 | to the server.</p> |
| 955 | </div> |
| 956 | <div class="literalblock"> |
| 957 | <div class="content"> |
| 958 | <pre> packfile-uris <comma-separated-list-of-protocols> |
| 959 | Indicates to the server that the client is willing to receive |
| 960 | URIs of any of the given protocols in place of objects in the |
| 961 | sent packfile. Before performing the connectivity check, the |
| 962 | client should download from all given URIs. Currently, the |
| 963 | protocols supported are "http" and "https".</pre> |
| 964 | </div> |
| 965 | </div> |
| 966 | <div class="paragraph"> |
| 967 | <p>If the <em>wait-for-done</em> feature is advertised, the following argument |
| 968 | can be included in the client’s request.</p> |
| 969 | </div> |
| 970 | <div class="literalblock"> |
| 971 | <div class="content"> |
| 972 | <pre> wait-for-done |
| 973 | Indicates to the server that it should never send "ready", but |
| 974 | should wait for the client to say "done" before sending the |
| 975 | packfile.</pre> |
| 976 | </div> |
| 977 | </div> |
| 978 | <div class="paragraph"> |
| 979 | <p>The response of <code>fetch</code> is broken into a number of sections separated by |
| 980 | delimiter packets (0001), with each section beginning with its section |
| 981 | header. Most sections are sent only when the packfile is sent.</p> |
| 982 | </div> |
| 983 | <div class="literalblock"> |
| 984 | <div class="content"> |
| 985 | <pre>output = acknowledgements flush-pkt | |
| 986 | [acknowledgments delim-pkt] [shallow-info delim-pkt] |
| 987 | [wanted-refs delim-pkt] [packfile-uris delim-pkt] |
| 988 | packfile flush-pkt</pre> |
| 989 | </div> |
| 990 | </div> |
| 991 | <div class="literalblock"> |
| 992 | <div class="content"> |
| 993 | <pre>acknowledgments = PKT-LINE("acknowledgments" LF) |
| 994 | (nak | *ack) |
| 995 | (ready) |
| 996 | ready = PKT-LINE("ready" LF) |
| 997 | nak = PKT-LINE("NAK" LF) |
| 998 | ack = PKT-LINE("ACK" SP obj-id LF)</pre> |
| 999 | </div> |
| 1000 | </div> |
| 1001 | <div class="literalblock"> |
| 1002 | <div class="content"> |
| 1003 | <pre>shallow-info = PKT-LINE("shallow-info" LF) |
| 1004 | *PKT-LINE((shallow | unshallow) LF) |
| 1005 | shallow = "shallow" SP obj-id |
| 1006 | unshallow = "unshallow" SP obj-id</pre> |
| 1007 | </div> |
| 1008 | </div> |
| 1009 | <div class="literalblock"> |
| 1010 | <div class="content"> |
| 1011 | <pre>wanted-refs = PKT-LINE("wanted-refs" LF) |
| 1012 | *PKT-LINE(wanted-ref LF) |
| 1013 | wanted-ref = obj-id SP refname</pre> |
| 1014 | </div> |
| 1015 | </div> |
| 1016 | <div class="literalblock"> |
| 1017 | <div class="content"> |
| 1018 | <pre>packfile-uris = PKT-LINE("packfile-uris" LF) *packfile-uri |
| 1019 | packfile-uri = PKT-LINE(40*(HEXDIGIT) SP *%x20-ff LF)</pre> |
| 1020 | </div> |
| 1021 | </div> |
| 1022 | <div class="literalblock"> |
| 1023 | <div class="content"> |
| 1024 | <pre>packfile = PKT-LINE("packfile" LF) |
| 1025 | *PKT-LINE(%x01-03 *%x00-ff)</pre> |
| 1026 | </div> |
| 1027 | </div> |
| 1028 | <div class="literalblock"> |
| 1029 | <div class="content"> |
| 1030 | <pre> acknowledgments section |
| 1031 | * If the client determines that it is finished with negotiations by |
| 1032 | sending a "done" line (thus requiring the server to send a packfile), |
| 1033 | the acknowledgments sections MUST be omitted from the server's |
| 1034 | response.</pre> |
| 1035 | </div> |
| 1036 | </div> |
| 1037 | <div class="ulist"> |
| 1038 | <ul> |
| 1039 | <li> |
| 1040 | <p>Always begins with the section header "acknowledgments"</p> |
| 1041 | </li> |
| 1042 | <li> |
| 1043 | <p>The server will respond with "NAK" if none of the object ids sent |
| 1044 | as have lines were common.</p> |
| 1045 | </li> |
| 1046 | <li> |
| 1047 | <p>The server will respond with "ACK obj-id" for all of the |
| 1048 | object ids sent as have lines which are common.</p> |
| 1049 | </li> |
| 1050 | <li> |
| 1051 | <p>A response cannot have both "ACK" lines as well as a "NAK" |
| 1052 | line.</p> |
| 1053 | </li> |
| 1054 | <li> |
| 1055 | <p>The server will respond with a "ready" line indicating that |
| 1056 | the server has found an acceptable common base and is ready to |
| 1057 | make and send a packfile (which will be found in the packfile |
| 1058 | section of the same response)</p> |
| 1059 | </li> |
| 1060 | <li> |
| 1061 | <p>If the server has found a suitable cut point and has decided |
| 1062 | to send a "ready" line, then the server can decide to (as an |
| 1063 | optimization) omit any "ACK" lines it would have sent during |
| 1064 | its response. This is because the server will have already |
| 1065 | determined the objects it plans to send to the client and no |
| 1066 | further negotiation is needed.</p> |
| 1067 | <div class="literalblock"> |
| 1068 | <div class="content"> |
| 1069 | <pre> shallow-info section |
| 1070 | * If the client has requested a shallow fetch/clone, a shallow |
| 1071 | client requests a fetch or the server is shallow then the |
| 1072 | server's response may include a shallow-info section. The |
| 1073 | shallow-info section will be included if (due to one of the |
| 1074 | above conditions) the server needs to inform the client of any |
| 1075 | shallow boundaries or adjustments to the clients already |
| 1076 | existing shallow boundaries.</pre> |
| 1077 | </div> |
| 1078 | </div> |
| 1079 | </li> |
| 1080 | <li> |
| 1081 | <p>Always begins with the section header "shallow-info"</p> |
| 1082 | </li> |
| 1083 | <li> |
| 1084 | <p>If a positive depth is requested, the server will compute the |
| 1085 | set of commits which are no deeper than the desired depth.</p> |
| 1086 | </li> |
| 1087 | <li> |
| 1088 | <p>The server sends a "shallow obj-id" line for each commit whose |
| 1089 | parents will not be sent in the following packfile.</p> |
| 1090 | </li> |
| 1091 | <li> |
| 1092 | <p>The server sends an "unshallow obj-id" line for each commit |
| 1093 | which the client has indicated is shallow, but is no longer |
| 1094 | shallow as a result of the fetch (due to its parents being |
| 1095 | sent in the following packfile).</p> |
| 1096 | </li> |
| 1097 | <li> |
| 1098 | <p>The server MUST NOT send any "unshallow" lines for anything |
| 1099 | which the client has not indicated was shallow as a part of |
| 1100 | its request.</p> |
| 1101 | <div class="literalblock"> |
| 1102 | <div class="content"> |
| 1103 | <pre> wanted-refs section |
| 1104 | * This section is only included if the client has requested a |
| 1105 | ref using a 'want-ref' line and if a packfile section is also |
| 1106 | included in the response.</pre> |
| 1107 | </div> |
| 1108 | </div> |
| 1109 | </li> |
| 1110 | <li> |
| 1111 | <p>Always begins with the section header "wanted-refs".</p> |
| 1112 | </li> |
| 1113 | <li> |
| 1114 | <p>The server will send a ref listing ("<oid> <refname>") for |
| 1115 | each reference requested using <em>want-ref</em> lines.</p> |
| 1116 | </li> |
| 1117 | <li> |
| 1118 | <p>The server MUST NOT send any refs which were not requested |
| 1119 | using <em>want-ref</em> lines.</p> |
| 1120 | <div class="literalblock"> |
| 1121 | <div class="content"> |
| 1122 | <pre> packfile-uris section |
| 1123 | * This section is only included if the client sent |
| 1124 | 'packfile-uris' and the server has at least one such URI to |
| 1125 | send.</pre> |
| 1126 | </div> |
| 1127 | </div> |
| 1128 | </li> |
| 1129 | <li> |
| 1130 | <p>Always begins with the section header "packfile-uris".</p> |
| 1131 | </li> |
| 1132 | <li> |
| 1133 | <p>For each URI the server sends, it sends a hash of the pack’s |
| 1134 | contents (as output by git index-pack) followed by the URI.</p> |
| 1135 | </li> |
| 1136 | <li> |
| 1137 | <p>The hashes are 40 hex characters long. When Git upgrades to a new |
| 1138 | hash algorithm, this might need to be updated. (It should match |
| 1139 | whatever index-pack outputs after "pack\t" or "keep\t".</p> |
| 1140 | <div class="literalblock"> |
| 1141 | <div class="content"> |
| 1142 | <pre> packfile section |
| 1143 | * This section is only included if the client has sent 'want' |
| 1144 | lines in its request and either requested that no more |
| 1145 | negotiation be done by sending 'done' or if the server has |
| 1146 | decided it has found a sufficient cut point to produce a |
| 1147 | packfile.</pre> |
| 1148 | </div> |
| 1149 | </div> |
| 1150 | </li> |
| 1151 | <li> |
| 1152 | <p>Always begins with the section header "packfile"</p> |
| 1153 | </li> |
| 1154 | <li> |
| 1155 | <p>The transmission of the packfile begins immediately after the |
| 1156 | section header</p> |
| 1157 | </li> |
| 1158 | <li> |
| 1159 | <p>The data transfer of the packfile is always multiplexed, using |
| 1160 | the same semantics of the <em>side-band-64k</em> capability from |
| 1161 | protocol version 1. This means that each packet, during the |
| 1162 | packfile data stream, is made up of a leading 4-byte pkt-line |
| 1163 | length (typical of the pkt-line format), followed by a 1-byte |
| 1164 | stream code, followed by the actual data.</p> |
| 1165 | <div class="literalblock"> |
| 1166 | <div class="content"> |
| 1167 | <pre> The stream code can be one of: |
| 1168 | 1 - pack data |
| 1169 | 2 - progress messages |
| 1170 | 3 - fatal error message just before stream aborts</pre> |
| 1171 | </div> |
| 1172 | </div> |
| 1173 | </li> |
| 1174 | </ul> |
| 1175 | </div> |
| 1176 | </div> |
| 1177 | <div class="sect2"> |
| 1178 | <h3 id="_server_option">server-option</h3> |
| 1179 | <div class="paragraph"> |
| 1180 | <p>If advertised, indicates that any number of server specific options can be |
| 1181 | included in a request. This is done by sending each option as a |
| 1182 | "server-option=<option>" capability line in the capability-list section of |
| 1183 | a request.</p> |
| 1184 | </div> |
| 1185 | <div class="paragraph"> |
| 1186 | <p>The provided options must not contain a NUL or LF character.</p> |
| 1187 | </div> |
| 1188 | </div> |
| 1189 | <div class="sect2"> |
Junio C Hamano | f4e4f53 | 2024-11-02 05:48:11 | [diff] [blame] | 1190 | <h3 id="_object_format">object-format</h3> |
Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1191 | <div class="paragraph"> |
| 1192 | <p>The server can advertise the <code>object-format</code> capability with a value <code>X</code> (in the |
| 1193 | form <code>object-format=X</code>) to notify the client that the server is able to deal |
| 1194 | with objects using hash algorithm X. If not specified, the server is assumed to |
| 1195 | only handle SHA-1. If the client would like to use a hash algorithm other than |
| 1196 | SHA-1, it should specify its object-format string.</p> |
| 1197 | </div> |
| 1198 | </div> |
| 1199 | <div class="sect2"> |
| 1200 | <h3 id="_session_idsession_id">session-id=<session-id></h3> |
| 1201 | <div class="paragraph"> |
| 1202 | <p>The server may advertise a session ID that can be used to identify this process |
| 1203 | across multiple requests. The client may advertise its own session ID back to |
| 1204 | the server as well.</p> |
| 1205 | </div> |
| 1206 | <div class="paragraph"> |
| 1207 | <p>Session IDs should be unique to a given process. They must fit within a |
| 1208 | packet-line, and must not contain non-printable or whitespace characters. The |
| 1209 | current implementation uses trace2 session IDs (see |
| 1210 | <a href="technical/api-trace2.html">api-trace2</a> for details), but this may change |
| 1211 | and users of the session ID should not rely on this fact.</p> |
| 1212 | </div> |
| 1213 | </div> |
| 1214 | <div class="sect2"> |
| 1215 | <h3 id="_object_info">object-info</h3> |
| 1216 | <div class="paragraph"> |
| 1217 | <p><code>object-info</code> is the command to retrieve information about one or more objects. |
| 1218 | Its main purpose is to allow a client to make decisions based on this |
| 1219 | information without having to fully fetch objects. Object size is the only |
| 1220 | information that is currently supported.</p> |
| 1221 | </div> |
| 1222 | <div class="paragraph"> |
| 1223 | <p>An <code>object-info</code> request takes the following arguments:</p> |
| 1224 | </div> |
| 1225 | <div class="literalblock"> |
| 1226 | <div class="content"> |
| 1227 | <pre>size |
| 1228 | Requests size information to be returned for each listed object id.</pre> |
| 1229 | </div> |
| 1230 | </div> |
| 1231 | <div class="literalblock"> |
| 1232 | <div class="content"> |
| 1233 | <pre>oid <oid> |
| 1234 | Indicates to the server an object which the client wants to obtain |
| 1235 | information for.</pre> |
| 1236 | </div> |
| 1237 | </div> |
| 1238 | <div class="paragraph"> |
| 1239 | <p>The response of <code>object-info</code> is a list of the requested object ids |
| 1240 | and associated requested information, each separated by a single space.</p> |
| 1241 | </div> |
| 1242 | <div class="literalblock"> |
| 1243 | <div class="content"> |
| 1244 | <pre>output = info flush-pkt</pre> |
| 1245 | </div> |
| 1246 | </div> |
| 1247 | <div class="literalblock"> |
| 1248 | <div class="content"> |
| 1249 | <pre>info = PKT-LINE(attrs) LF) |
| 1250 | *PKT-LINE(obj-info LF)</pre> |
| 1251 | </div> |
| 1252 | </div> |
| 1253 | <div class="literalblock"> |
| 1254 | <div class="content"> |
| 1255 | <pre>attrs = attr | attrs SP attrs</pre> |
| 1256 | </div> |
| 1257 | </div> |
| 1258 | <div class="literalblock"> |
| 1259 | <div class="content"> |
| 1260 | <pre>attr = "size"</pre> |
| 1261 | </div> |
| 1262 | </div> |
| 1263 | <div class="literalblock"> |
| 1264 | <div class="content"> |
| 1265 | <pre>obj-info = obj-id SP obj-size</pre> |
| 1266 | </div> |
| 1267 | </div> |
| 1268 | </div> |
| 1269 | <div class="sect2"> |
| 1270 | <h3 id="_bundle_uri">bundle-uri</h3> |
| 1271 | <div class="paragraph"> |
| 1272 | <p>If the <em>bundle-uri</em> capability is advertised, the server supports the |
| 1273 | ‘bundle-uri’ command.</p> |
| 1274 | </div> |
| 1275 | <div class="paragraph"> |
| 1276 | <p>The capability is currently advertised with no value (i.e. not |
| 1277 | "bundle-uri=somevalue"), a value may be added in the future for |
| 1278 | supporting command-wide extensions. Clients MUST ignore any unknown |
| 1279 | capability values and proceed with the 'bundle-uri` dialog they |
| 1280 | support.</p> |
| 1281 | </div> |
| 1282 | <div class="paragraph"> |
| 1283 | <p>The <em>bundle-uri</em> command is intended to be issued before <code>fetch</code> to |
| 1284 | get URIs to bundle files (see <a href="git-bundle.html">git-bundle(1)</a>) to "seed" and |
| 1285 | inform the subsequent <code>fetch</code> command.</p> |
| 1286 | </div> |
| 1287 | <div class="paragraph"> |
| 1288 | <p>The client CAN issue <code>bundle-uri</code> before or after any other valid |
| 1289 | command. To be useful to clients it’s expected that it’ll be issued |
| 1290 | after an <code>ls-refs</code> and before <code>fetch</code>, but CAN be issued at any time |
| 1291 | in the dialog.</p> |
| 1292 | </div> |
| 1293 | <div class="sect3"> |
| 1294 | <h4 id="_discussion_of_bundle_uri">DISCUSSION of bundle-uri</h4> |
| 1295 | <div class="paragraph"> |
| 1296 | <p>The intent of the feature is optimize for server resource consumption |
| 1297 | in the common case by changing the common case of fetching a very |
| 1298 | large PACK during <a href="git-clone.html">git-clone(1)</a> into a smaller incremental |
| 1299 | fetch.</p> |
| 1300 | </div> |
| 1301 | <div class="paragraph"> |
| 1302 | <p>It also allows servers to achieve better caching in combination with |
| 1303 | an <code>uploadpack.packObjectsHook</code> (see <a href="git-config.html">git-config(1)</a>).</p> |
| 1304 | </div> |
| 1305 | <div class="paragraph"> |
| 1306 | <p>By having new clones or fetches be a more predictable and common |
| 1307 | negotiation against the tips of recently produces *.bundle file(s). |
| 1308 | Servers might even pre-generate the results of such negotiations for |
| 1309 | the <code>uploadpack.packObjectsHook</code> as new pushes come in.</p> |
| 1310 | </div> |
| 1311 | <div class="paragraph"> |
| 1312 | <p>One way that servers could take advantage of these bundles is that the |
| 1313 | server would anticipate that fresh clones will download a known bundle, |
| 1314 | followed by catching up to the current state of the repository using ref |
| 1315 | tips found in that bundle (or bundles).</p> |
| 1316 | </div> |
| 1317 | </div> |
| 1318 | <div class="sect3"> |
| 1319 | <h4 id="_protocol_for_bundle_uri">PROTOCOL for bundle-uri</h4> |
| 1320 | <div class="paragraph"> |
| 1321 | <p>A <code>bundle-uri</code> request takes no arguments, and as noted above does not |
| 1322 | currently advertise a capability value. Both may be added in the |
| 1323 | future.</p> |
| 1324 | </div> |
| 1325 | <div class="paragraph"> |
| 1326 | <p>When the client issues a <code>command=bundle-uri</code> request, the response is a |
| 1327 | list of key-value pairs provided as packet lines with value |
Junio C Hamano | dc39238 | 2024-10-11 18:57:29 | [diff] [blame] | 1328 | <em><key></em><code>=</code><em><value></em>. Each <em><key></em> should be interpreted as a config key from |
| 1329 | the <code>bundle.</code>* namespace to construct a list of bundles. These keys are |
| 1330 | grouped by a <code>bundle.</code><em><id></em>. subsection, where each key corresponding to a |
| 1331 | given <em><id></em> contributes attributes to the bundle defined by that <em><id></em>. |
Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1332 | See <a href="git-config.html">git-config(1)</a> for the specific details of these keys and how |
| 1333 | the Git client will interpret their values.</p> |
| 1334 | </div> |
| 1335 | <div class="paragraph"> |
| 1336 | <p>Clients MUST parse the line according to the above format, lines that do |
| 1337 | not conform to the format SHOULD be discarded. The user MAY be warned in |
| 1338 | such a case.</p> |
| 1339 | </div> |
| 1340 | </div> |
| 1341 | <div class="sect3"> |
| 1342 | <h4 id="_bundle_uri_client_and_server_expectations">bundle-uri CLIENT AND SERVER EXPECTATIONS</h4> |
| 1343 | <div class="dlist"> |
| 1344 | <dl> |
| 1345 | <dt class="hdlist1">URI CONTENTS</dt> |
| 1346 | <dd> |
| 1347 | <p>The content at the advertised URIs MUST be one of two types.</p> |
| 1348 | <div class="paragraph"> |
Junio C Hamano | dc39238 | 2024-10-11 18:57:29 | [diff] [blame] | 1349 | <p>The advertised URI may contain a bundle file that <code>git</code> <code>bundle</code> <code>verify</code> |
Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1350 | would accept. I.e. they MUST contain one or more reference tips for |
| 1351 | use by the client, MUST indicate prerequisites (in any) with standard |
| 1352 | "-" prefixes, and MUST indicate their "object-format", if |
| 1353 | applicable.</p> |
| 1354 | </div> |
| 1355 | <div class="paragraph"> |
Junio C Hamano | dc39238 | 2024-10-11 18:57:29 | [diff] [blame] | 1356 | <p>The advertised URI may alternatively contain a plaintext file that <code>git</code> |
| 1357 | <code>config</code> <code>--list</code> would accept (with the <code>--file</code> option). The key-value |
| 1358 | pairs in this list are in the <code>bundle.</code>* namespace (see |
Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1359 | <a href="git-config.html">git-config(1)</a>).</p> |
| 1360 | </div> |
| 1361 | </dd> |
| 1362 | <dt class="hdlist1">bundle-uri CLIENT ERROR RECOVERY</dt> |
| 1363 | <dd> |
| 1364 | <p>A client MUST above all gracefully degrade on errors, whether that |
| 1365 | error is because of bad missing/data in the bundle URI(s), because |
| 1366 | that client is too dumb to e.g. understand and fully parse out bundle |
| 1367 | headers and their prerequisite relationships, or something else.</p> |
| 1368 | <div class="paragraph"> |
| 1369 | <p>Server operators should feel confident in turning on "bundle-uri" and |
| 1370 | not worry if e.g. their CDN goes down that clones or fetches will run |
| 1371 | into hard failures. Even if the server bundle(s) are |
| 1372 | incomplete, or bad in some way the client should still end up with a |
| 1373 | functioning repository, just as if it had chosen not to use this |
| 1374 | protocol extension.</p> |
| 1375 | </div> |
| 1376 | <div class="paragraph"> |
| 1377 | <p>All subsequent discussion on client and server interaction MUST keep |
| 1378 | this in mind.</p> |
| 1379 | </div> |
| 1380 | </dd> |
| 1381 | <dt class="hdlist1">bundle-uri SERVER TO CLIENT</dt> |
| 1382 | <dd> |
| 1383 | <p>The ordering of the returned bundle uris is not significant. Clients |
| 1384 | MUST parse their headers to discover their contained OIDS and |
| 1385 | prerequisites. A client MUST consider the content of the bundle(s) |
| 1386 | themselves and their header as the ultimate source of truth.</p> |
| 1387 | <div class="paragraph"> |
| 1388 | <p>A server MAY even return bundle(s) that don’t have any direct |
| 1389 | relationship to the repository being cloned (either through accident, |
| 1390 | or intentional "clever" configuration), and expect a client to sort |
| 1391 | out what data they’d like from the bundle(s), if any.</p> |
| 1392 | </div> |
| 1393 | </dd> |
| 1394 | <dt class="hdlist1">bundle-uri CLIENT TO SERVER</dt> |
| 1395 | <dd> |
| 1396 | <p>The client SHOULD provide reference tips found in the bundle header(s) |
| 1397 | as <em>have</em> lines in any subsequent <code>fetch</code> request. A client MAY also |
| 1398 | ignore the bundle(s) entirely if doing so is deemed worse for some |
| 1399 | reason, e.g. if the bundles can’t be downloaded, it doesn’t like the |
| 1400 | tips it finds etc.</p> |
| 1401 | </dd> |
| 1402 | <dt class="hdlist1">WHEN ADVERTISED BUNDLE(S) REQUIRE NO FURTHER NEGOTIATION</dt> |
| 1403 | <dd> |
| 1404 | <p>If after issuing <code>bundle-uri</code> and <code>ls-refs</code>, and getting the header(s) |
| 1405 | of the bundle(s) the client finds that the ref tips it wants can be |
| 1406 | retrieved entirely from advertised bundle(s), the client MAY disconnect |
| 1407 | from the Git server. The results of such a <em>clone</em> or <em>fetch</em> should be |
| 1408 | indistinguishable from the state attained without using bundle-uri.</p> |
| 1409 | </dd> |
| 1410 | <dt class="hdlist1">EARLY CLIENT DISCONNECTIONS AND ERROR RECOVERY</dt> |
| 1411 | <dd> |
| 1412 | <p>A client MAY perform an early disconnect while still downloading the |
| 1413 | bundle(s) (having streamed and parsed their headers). In such a case |
| 1414 | the client MUST gracefully recover from any errors related to |
| 1415 | finishing the download and validation of the bundle(s).</p> |
| 1416 | <div class="paragraph"> |
| 1417 | <p>I.e. a client might need to re-connect and issue a <em>fetch</em> command, |
| 1418 | and possibly fall back to not making use of <em>bundle-uri</em> at all.</p> |
| 1419 | </div> |
| 1420 | <div class="paragraph"> |
| 1421 | <p>This "MAY" behavior is specified as such (and not a "SHOULD") on the |
| 1422 | assumption that a server advertising bundle uris is more likely than |
| 1423 | not to be serving up a relatively large repository, and to be pointing |
| 1424 | to URIs that have a good chance of being in working order. A client |
| 1425 | MAY e.g. look at the payload size of the bundles as a heuristic to see |
| 1426 | if an early disconnect is worth it, should falling back on a full |
| 1427 | "fetch" dialog be necessary.</p> |
| 1428 | </div> |
| 1429 | </dd> |
| 1430 | <dt class="hdlist1">WHEN ADVERTISED BUNDLE(S) REQUIRE FURTHER NEGOTIATION</dt> |
| 1431 | <dd> |
| 1432 | <p>A client SHOULD commence a negotiation of a PACK from the server via |
| 1433 | the "fetch" command using the OID tips found in advertised bundles, |
| 1434 | even if’s still in the process of downloading those bundle(s).</p> |
| 1435 | <div class="paragraph"> |
| 1436 | <p>This allows for aggressive early disconnects from any interactive |
| 1437 | server dialog. The client blindly trusts that the advertised OID tips |
| 1438 | are relevant, and issues them as <em>have</em> lines, it then requests any |
| 1439 | tips it would like (usually from the "ls-refs" advertisement) via |
| 1440 | <em>want</em> lines. The server will then compute a (hopefully small) PACK |
| 1441 | with the expected difference between the tips from the bundle(s) and |
| 1442 | the data requested.</p> |
| 1443 | </div> |
| 1444 | <div class="paragraph"> |
| 1445 | <p>The only connection the client then needs to keep active is to the |
| 1446 | concurrently downloading static bundle(s), when those and the |
| 1447 | incremental PACK are retrieved they should be inflated and |
| 1448 | validated. Any errors at this point should be gracefully recovered |
| 1449 | from, see above.</p> |
| 1450 | </div> |
| 1451 | </dd> |
| 1452 | </dl> |
| 1453 | </div> |
| 1454 | </div> |
| 1455 | <div class="sect3"> |
| 1456 | <h4 id="_bundle_uri_protocol_features">bundle-uri PROTOCOL FEATURES</h4> |
| 1457 | <div class="paragraph"> |
Junio C Hamano | dc39238 | 2024-10-11 18:57:29 | [diff] [blame] | 1458 | <p>The client constructs a bundle list from the <em><key></em><code>=</code><em><value></em> pairs |
| 1459 | provided by the server. These pairs are part of the <code>bundle.</code>* namespace |
Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1460 | as documented in <a href="git-config.html">git-config(1)</a>. In this section, we discuss some |
| 1461 | of these keys and describe the actions the client will do in response to |
| 1462 | this information.</p> |
| 1463 | </div> |
| 1464 | <div class="paragraph"> |
| 1465 | <p>In particular, the <code>bundle.version</code> key specifies an integer value. The |
| 1466 | only accepted value at the moment is <code>1</code>, but if the client sees an |
| 1467 | unexpected value here then the client MUST ignore the bundle list.</p> |
| 1468 | </div> |
| 1469 | <div class="paragraph"> |
| 1470 | <p>As long as <code>bundle.version</code> is understood, all other unknown keys MAY be |
| 1471 | ignored by the client. The server will guarantee compatibility with older |
| 1472 | clients, though newer clients may be better able to use the extra keys to |
| 1473 | minimize downloads.</p> |
| 1474 | </div> |
| 1475 | <div class="paragraph"> |
| 1476 | <p>Any backwards-incompatible addition of pre-URI key-value will be |
| 1477 | guarded by a new <code>bundle.version</code> value or values in <em>bundle-uri</em> |
| 1478 | capability advertisement itself, and/or by new future <code>bundle-uri</code> |
| 1479 | request arguments.</p> |
| 1480 | </div> |
| 1481 | <div class="paragraph"> |
| 1482 | <p>Some example key-value pairs that are not currently implemented but could |
| 1483 | be implemented in the future include:</p> |
| 1484 | </div> |
| 1485 | <div class="ulist"> |
| 1486 | <ul> |
| 1487 | <li> |
| 1488 | <p>Add a "hash=<val>" or "size=<bytes>" advertise the expected hash or |
| 1489 | size of the bundle file.</p> |
| 1490 | </li> |
| 1491 | <li> |
| 1492 | <p>Advertise that one or more bundle files are the same (to e.g. have |
| 1493 | clients round-robin or otherwise choose one of N possible files).</p> |
| 1494 | </li> |
| 1495 | <li> |
| 1496 | <p>A "oid=<OID>" shortcut and "prerequisite=<OID>" shortcut. For |
| 1497 | expressing the common case of a bundle with one tip and no |
| 1498 | prerequisites, or one tip and one prerequisite.</p> |
| 1499 | <div class="paragraph"> |
| 1500 | <p>This would allow for optimizing the common case of servers who’d like |
| 1501 | to provide one "big bundle" containing only their "main" branch, |
| 1502 | and/or incremental updates thereof.</p> |
| 1503 | </div> |
| 1504 | <div class="paragraph"> |
Junio C Hamano | f4e4f53 | 2024-11-02 05:48:11 | [diff] [blame] | 1505 | <p>A client receiving such a response MAY assume that they can skip |
Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1506 | retrieving the header from a bundle at the indicated URI, and thus |
| 1507 | save themselves and the server(s) the request(s) needed to inspect the |
| 1508 | headers of that bundle or bundles.</p> |
| 1509 | </div> |
| 1510 | </li> |
| 1511 | </ul> |
| 1512 | </div> |
| 1513 | </div> |
| 1514 | </div> |
| 1515 | </div> |
| 1516 | </div> |
| 1517 | <div class="sect1"> |
| 1518 | <h2 id="_git">GIT</h2> |
| 1519 | <div class="sectionbody"> |
| 1520 | <div class="paragraph"> |
| 1521 | <p>Part of the <a href="git.html">git(1)</a> suite</p> |
| 1522 | </div> |
| 1523 | </div> |
| 1524 | </div> |
| 1525 | </div> |
| 1526 | <div id="footer"> |
| 1527 | <div id="footer-text"> |
Junio C Hamano | f4e4f53 | 2024-11-02 05:48:11 | [diff] [blame] | 1528 | Last updated 2024-11-01 22:46:55 -0700 |
Junio C Hamano | b96f40a | 2024-08-01 00:57:25 | [diff] [blame] | 1529 | </div> |
| 1530 | </div> |
| 1531 | </body> |
| 1532 | </html> |