| <!DOCTYPE html> | |
| <html xmlns="http://www.w3.org/1999/xhtml" lang="en"> | |
| <head> | |
| <meta charset="UTF-8"/> | |
| <meta http-equiv="X-UA-Compatible" content="IE=edge"/> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"/> | |
| <meta name="generator" content="Asciidoctor 2.0.26"/> | |
| <title>gitprotocol-v2(5)</title> | |
| <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"/> | |
| <style> | |
| /*! Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */ | |
| /* Uncomment the following line when using as a custom stylesheet */ | |
| /* @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"; */ | |
| html{font-family:sans-serif;-webkit-text-size-adjust:100%} | |
| a{background:none} | |
| a:focus{outline:thin dotted} | |
| a:active,a:hover{outline:0} | |
| h1{font-size:2em;margin:.67em 0} | |
| b,strong{font-weight:bold} | |
| abbr{font-size:.9em} | |
| abbr[title]{cursor:help;border-bottom:1px dotted #dddddf;text-decoration:none} | |
| dfn{font-style:italic} | |
| hr{height:0} | |
| mark{background:#ff0;color:#000} | |
| code,kbd,pre,samp{font-family:monospace;font-size:1em} | |
| pre{white-space:pre-wrap} | |
| q{quotes:"\201C" "\201D" "\2018" "\2019"} | |
| small{font-size:80%} | |
| sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline} | |
| sup{top:-.5em} | |
| sub{bottom:-.25em} | |
| img{border:0} | |
| svg:not(:root){overflow:hidden} | |
| figure{margin:0} | |
| audio,video{display:inline-block} | |
| audio:not([controls]){display:none;height:0} | |
| fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em} | |
| legend{border:0;padding:0} | |
| button,input,select,textarea{font-family:inherit;font-size:100%;margin:0} | |
| button,input{line-height:normal} | |
| button,select{text-transform:none} | |
| button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer} | |
| button[disabled],html input[disabled]{cursor:default} | |
| input[type=checkbox],input[type=radio]{padding:0} | |
| button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0} | |
| textarea{overflow:auto;vertical-align:top} | |
| table{border-collapse:collapse;border-spacing:0} | |
| *,::before,::after{box-sizing:border-box} | |
| html,body{font-size:100%} | |
| 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} | |
| a:hover{cursor:pointer} | |
| img,object,embed{max-width:100%;height:auto} | |
| object,embed{height:100%} | |
| img{-ms-interpolation-mode:bicubic} | |
| .left{float:left!important} | |
| .right{float:right!important} | |
| .text-left{text-align:left!important} | |
| .text-right{text-align:right!important} | |
| .text-center{text-align:center!important} | |
| .text-justify{text-align:justify!important} | |
| .hide{display:none} | |
| img,object,svg{display:inline-block;vertical-align:middle} | |
| textarea{height:auto;min-height:50px} | |
| select{width:100%} | |
| .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} | |
| 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} | |
| a{color:#2156a5;text-decoration:underline;line-height:inherit} | |
| a:hover,a:focus{color:#1d4b8f} | |
| a img{border:0} | |
| p{line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility} | |
| p aside{font-size:.875em;line-height:1.35;font-style:italic} | |
| 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} | |
| 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} | |
| h1{font-size:2.125em} | |
| h2{font-size:1.6875em} | |
| h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em} | |
| h4,h5{font-size:1.125em} | |
| h6{font-size:1em} | |
| hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em} | |
| em,i{font-style:italic;line-height:inherit} | |
| strong,b{font-weight:bold;line-height:inherit} | |
| small{font-size:60%;line-height:inherit} | |
| code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)} | |
| ul,ol,dl{line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit} | |
| ul,ol{margin-left:1.5em} | |
| ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0} | |
| ul.circle{list-style-type:circle} | |
| ul.disc{list-style-type:disc} | |
| ul.square{list-style-type:square} | |
| ul.circle ul:not([class]),ul.disc ul:not([class]),ul.square ul:not([class]){list-style:inherit} | |
| ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0} | |
| dl dt{margin-bottom:.3125em;font-weight:bold} | |
| dl dd{margin-bottom:1.25em} | |
| blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd} | |
| blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)} | |
| @media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2} | |
| h1{font-size:2.75em} | |
| h2{font-size:2.3125em} | |
| h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em} | |
| h4{font-size:1.4375em}} | |
| table{background:#fff;margin-bottom:1.25em;border:1px solid #dedede;word-wrap:normal} | |
| table thead,table tfoot{background:#f7f8f7} | |
| 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} | |
| table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)} | |
| table tr.even,table tr.alt{background:#f8f8f7} | |
| table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{line-height:1.6} | |
| h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em} | |
| h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400} | |
| .center{margin-left:auto;margin-right:auto} | |
| .stretch{width:100%} | |
| .clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table} | |
| .clearfix::after,.float-group::after{clear:both} | |
| :not(pre).nobreak{word-wrap:normal} | |
| :not(pre).nowrap{white-space:nowrap} | |
| :not(pre).pre-wrap{white-space:pre-wrap} | |
| :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} | |
| pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed} | |
| pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit} | |
| pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal} | |
| em em{font-style:normal} | |
| strong strong{font-weight:400} | |
| .keyseq{color:rgba(51,51,51,.8)} | |
| 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} | |
| .keyseq kbd:first-child{margin-left:0} | |
| .keyseq kbd:last-child{margin-right:0} | |
| .menuseq,.menuref{color:#000} | |
| .menuseq b:not(.caret),.menuref{font-weight:inherit} | |
| .menuseq{word-spacing:-.02em} | |
| .menuseq b.caret{font-size:1.25em;line-height:.8} | |
| .menuseq i.caret{font-weight:bold;text-align:center;width:.45em} | |
| b.button::before,b.button::after{position:relative;top:-1px;font-weight:400} | |
| b.button::before{content:"[";padding:0 3px 0 2px} | |
| b.button::after{content:"]";padding:0 2px 0 3px} | |
| p a>code:hover{color:rgba(0,0,0,.9)} | |
| #header,#content,#footnotes,#footer{width:100%;margin:0 auto;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em} | |
| #header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table} | |
| #header::after,#content::after,#footnotes::after,#footer::after{clear:both} | |
| #content{margin-top:1.25em} | |
| #content::before{content:none} | |
| #header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0} | |
| #header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf} | |
| #header>h1:only-child{border-bottom:1px solid #dddddf;padding-bottom:8px} | |
| #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} | |
| #header .details span:first-child{margin-left:-.125em} | |
| #header .details span.email a{color:rgba(0,0,0,.85)} | |
| #header .details br{display:none} | |
| #header .details br+span::before{content:"\00a0\2013\00a0"} | |
| #header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)} | |
| #header .details br+span#revremark::before{content:"\00a0|\00a0"} | |
| #header #revnumber{text-transform:capitalize} | |
| #header #revnumber::after{content:"\00a0"} | |
| #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} | |
| #toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em} | |
| #toc>ul{margin-left:.125em} | |
| #toc ul.sectlevel0>li>a{font-style:italic} | |
| #toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0} | |
| #toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none} | |
| #toc li{line-height:1.3334;margin-top:.3334em} | |
| #toc a{text-decoration:none} | |
| #toc a:active{text-decoration:underline} | |
| #toctitle{color:#7a2518;font-size:1.2em} | |
| @media screen and (min-width:768px){#toctitle{font-size:1.375em} | |
| body.toc2{padding-left:15em;padding-right:0} | |
| body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px} | |
| #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} | |
| #toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em} | |
| #toc.toc2>ul{font-size:.9em;margin-bottom:0} | |
| #toc.toc2 ul ul{margin-left:0;padding-left:1em} | |
| #toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em} | |
| body.toc2.toc-right{padding-left:0;padding-right:15em} | |
| body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}} | |
| @media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0} | |
| #toc.toc2{width:20em} | |
| #toc.toc2 #toctitle{font-size:1.375em} | |
| #toc.toc2>ul{font-size:.95em} | |
| #toc.toc2 ul ul{padding-left:1.25em} | |
| body.toc2.toc-right{padding-left:0;padding-right:20em}} | |
| #content #toc{border:1px solid #e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;border-radius:4px} | |
| #content #toc>:first-child{margin-top:0} | |
| #content #toc>:last-child{margin-bottom:0} | |
| #footer{max-width:none;background:rgba(0,0,0,.8);padding:1.25em} | |
| #footer-text{color:hsla(0,0%,100%,.8);line-height:1.44} | |
| #content{margin-bottom:.625em} | |
| .sect1{padding-bottom:.625em} | |
| @media screen and (min-width:768px){#content{margin-bottom:1.25em} | |
| .sect1{padding-bottom:1.25em}} | |
| .sect1:last-child{padding-bottom:0} | |
| .sect1+.sect1{border-top:1px solid #e7e7e9} | |
| #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} | |
| #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} | |
| #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} | |
| #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} | |
| #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} | |
| details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em} | |
| details{margin-left:1.25rem} | |
| details>summary{cursor:pointer;display:block;position:relative;line-height:1.6;margin-bottom:.625rem;outline:none;-webkit-tap-highlight-color:transparent} | |
| details>summary::-webkit-details-marker{display:none} | |
| 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%)} | |
| details[open]>summary::before{border:solid transparent;border-top:solid;border-width:.5em .3em 0;transform:translateY(15%)} | |
| details>summary::after{content:"";width:1.25rem;height:1em;position:absolute;top:.3em;left:-1.25rem} | |
| .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} | |
| table.tableblock.fit-content>caption.title{white-space:nowrap;width:0} | |
| .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)} | |
| .admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%} | |
| .admonitionblock>table td.icon{text-align:center;width:80px} | |
| .admonitionblock>table td.icon img{max-width:none} | |
| .admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase} | |
| .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} | |
| .admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0} | |
| .exampleblock>.content{border:1px solid #e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;border-radius:4px} | |
| .sidebarblock{border:1px solid #dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;border-radius:4px} | |
| .sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center} | |
| .exampleblock>.content>:first-child,.sidebarblock>.content>:first-child{margin-top:0} | |
| .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} | |
| .literalblock pre,.listingblock>.content>pre{border-radius:4px;overflow-x:auto;padding:1em;font-size:.8125em} | |
| @media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}} | |
| @media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}} | |
| .literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class=highlight],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8} | |
| .literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)} | |
| .listingblock>.content{position:relative} | |
| .listingblock pre>code{display:block} | |
| .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} | |
| .listingblock:hover code[data-lang]::before{display:block} | |
| .listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5} | |
| .listingblock.terminal pre .command:not([data-prompt])::before{content:"$"} | |
| .listingblock pre.highlightjs{padding:0} | |
| .listingblock pre.highlightjs>code{padding:1em;border-radius:4px} | |
| .listingblock pre.prettyprint{border-width:0} | |
| .prettyprint{background:#f7f7f8} | |
| pre.prettyprint .linenums{line-height:1.45;margin-left:2em} | |
| pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0} | |
| pre.prettyprint li code[data-lang]::before{opacity:1} | |
| pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none} | |
| table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none} | |
| table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal} | |
| table.linenotable td.code{padding-left:.75em} | |
| 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} | |
| pre.pygments span.linenos{display:inline-block;margin-right:.75em} | |
| .quoteblock{margin:0 1em 1.25em 1.5em;display:table} | |
| .quoteblock:not(.excerpt)>.title{margin-left:-1.5em;margin-bottom:.75em} | |
| .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} | |
| .quoteblock blockquote{margin:0;padding:0;border:0} | |
| .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)} | |
| .quoteblock blockquote>.paragraph:last-child p{margin-bottom:0} | |
| .quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right} | |
| .verseblock{margin:0 1em 1.25em} | |
| .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} | |
| .verseblock pre strong{font-weight:400} | |
| .verseblock .attribution{margin-top:1.25rem;margin-left:.5ex} | |
| .quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic} | |
| .quoteblock .attribution br,.verseblock .attribution br{display:none} | |
| .quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)} | |
| .quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none} | |
| .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} | |
| .quoteblock.abstract{margin:0 1em 1.25em;display:block} | |
| .quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center} | |
| .quoteblock.excerpt>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf} | |
| .quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0} | |
| .quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem} | |
| .quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;font-size:.85rem;text-align:left;margin-right:0} | |
| p.tableblock:last-child{margin-bottom:0} | |
| td.tableblock>.content{margin-bottom:1.25em;word-wrap:anywhere} | |
| td.tableblock>.content>:last-child{margin-bottom:-1.25em} | |
| table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede} | |
| table.grid-all>*>tr>*{border-width:1px} | |
| table.grid-cols>*>tr>*{border-width:0 1px} | |
| table.grid-rows>*>tr>*{border-width:1px 0} | |
| table.frame-all{border-width:1px} | |
| table.frame-ends{border-width:1px 0} | |
| table.frame-sides{border-width:0 1px} | |
| table.frame-none>colgroup+*>:first-child>*,table.frame-sides>colgroup+*>:first-child>*{border-top-width:0} | |
| table.frame-none>:last-child>:last-child>*,table.frame-sides>:last-child>:last-child>*{border-bottom-width:0} | |
| table.frame-none>*>tr>:first-child,table.frame-ends>*>tr>:first-child{border-left-width:0} | |
| table.frame-none>*>tr>:last-child,table.frame-ends>*>tr>:last-child{border-right-width:0} | |
| 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} | |
| th.halign-left,td.halign-left{text-align:left} | |
| th.halign-right,td.halign-right{text-align:right} | |
| th.halign-center,td.halign-center{text-align:center} | |
| th.valign-top,td.valign-top{vertical-align:top} | |
| th.valign-bottom,td.valign-bottom{vertical-align:bottom} | |
| th.valign-middle,td.valign-middle{vertical-align:middle} | |
| table thead th,table tfoot th{font-weight:bold} | |
| tbody tr th{background:#f7f8f7} | |
| tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold} | |
| p.tableblock>code:only-child{background:none;padding:0} | |
| p.tableblock{font-size:1em} | |
| ol{margin-left:1.75em} | |
| ul li ol{margin-left:1.5em} | |
| dl dd{margin-left:1.125em} | |
| dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0} | |
| li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em} | |
| ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none} | |
| ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em} | |
| ul.unstyled,ol.unstyled{margin-left:0} | |
| li>p:empty:only-child::before{content:"";display:inline-block} | |
| ul.checklist>li>p:first-child{margin-left:-1em} | |
| 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} | |
| ul.checklist>li>p:first-child>input[type=checkbox]:first-child{margin-right:.25em} | |
| ul.inline{display:flex;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em} | |
| ul.inline>li{margin-left:1.25em} | |
| .unstyled dl dt{font-weight:400;font-style:normal} | |
| ol.arabic{list-style-type:decimal} | |
| ol.decimal{list-style-type:decimal-leading-zero} | |
| ol.loweralpha{list-style-type:lower-alpha} | |
| ol.upperalpha{list-style-type:upper-alpha} | |
| ol.lowerroman{list-style-type:lower-roman} | |
| ol.upperroman{list-style-type:upper-roman} | |
| ol.lowergreek{list-style-type:lower-greek} | |
| .hdlist>table,.colist>table{border:0;background:none} | |
| .hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none} | |
| td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em} | |
| td.hdlist1{font-weight:bold;padding-bottom:1.25em} | |
| td.hdlist2{word-wrap:anywhere} | |
| .literalblock+.colist,.listingblock+.colist{margin-top:-.5em} | |
| .colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top} | |
| .colist td:not([class]):first-child img{max-width:none} | |
| .colist td:not([class]):last-child{padding:.25em 0} | |
| .thumb,.th{line-height:0;display:inline-block;border:4px solid #fff;box-shadow:0 0 0 1px #ddd} | |
| .imageblock.left{margin:.25em .625em 1.25em 0} | |
| .imageblock.right{margin:.25em 0 1.25em .625em} | |
| .imageblock>.title{margin-bottom:0} | |
| .imageblock.thumb,.imageblock.th{border-width:6px} | |
| .imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em} | |
| .image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0} | |
| .image.left{margin-right:.625em} | |
| .image.right{margin-left:.625em} | |
| a.image{text-decoration:none;display:inline-block} | |
| a.image object{pointer-events:none} | |
| sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super} | |
| sup.footnote a,sup.footnoteref a{text-decoration:none} | |
| sup.footnote a:active,sup.footnoteref a:active,#footnotes .footnote a:first-of-type:active{text-decoration:underline} | |
| #footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em} | |
| #footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0} | |
| #footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em} | |
| #footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em} | |
| #footnotes .footnote:last-of-type{margin-bottom:0} | |
| #content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0} | |
| div.unbreakable{page-break-inside:avoid} | |
| .big{font-size:larger} | |
| .small{font-size:smaller} | |
| .underline{text-decoration:underline} | |
| .overline{text-decoration:overline} | |
| .line-through{text-decoration:line-through} | |
| .aqua{color:#00bfbf} | |
| .aqua-background{background:#00fafa} | |
| .black{color:#000} | |
| .black-background{background:#000} | |
| .blue{color:#0000bf} | |
| .blue-background{background:#0000fa} | |
| .fuchsia{color:#bf00bf} | |
| .fuchsia-background{background:#fa00fa} | |
| .gray{color:#606060} | |
| .gray-background{background:#7d7d7d} | |
| .green{color:#006000} | |
| .green-background{background:#007d00} | |
| .lime{color:#00bf00} | |
| .lime-background{background:#00fa00} | |
| .maroon{color:#600000} | |
| .maroon-background{background:#7d0000} | |
| .navy{color:#000060} | |
| .navy-background{background:#00007d} | |
| .olive{color:#606000} | |
| .olive-background{background:#7d7d00} | |
| .purple{color:#600060} | |
| .purple-background{background:#7d007d} | |
| .red{color:#bf0000} | |
| .red-background{background:#fa0000} | |
| .silver{color:#909090} | |
| .silver-background{background:#bcbcbc} | |
| .teal{color:#006060} | |
| .teal-background{background:#007d7d} | |
| .white{color:#bfbfbf} | |
| .white-background{background:#fafafa} | |
| .yellow{color:#bfbf00} | |
| .yellow-background{background:#fafa00} | |
| span.icon>.fa{cursor:default} | |
| a span.icon>.fa{cursor:inherit} | |
| .admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default} | |
| .admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c} | |
| .admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111} | |
| .admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900} | |
| .admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400} | |
| .admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000} | |
| .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} | |
| .conum[data-value] *{color:#fff!important} | |
| .conum[data-value]+b{display:none} | |
| .conum[data-value]::after{content:attr(data-value)} | |
| pre .conum[data-value]{position:relative;top:-.125em} | |
| b.conum *{color:inherit!important} | |
| .conum:not([data-value]):empty{display:none} | |
| dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility} | |
| h1,h2,p,td.content,span.alt,summary{letter-spacing:-.01em} | |
| p strong,td.content strong,div.footnote strong{letter-spacing:-.005em} | |
| p,blockquote,dt,td.content,td.hdlist1,span.alt,summary{font-size:1.0625rem} | |
| p{margin-bottom:1.25rem} | |
| .sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em} | |
| .exampleblock>.content{background:#fffef7;border-color:#e0e0dc;box-shadow:0 1px 4px #e0e0dc} | |
| .print-only{display:none!important} | |
| @page{margin:1.25cm .75cm} | |
| @media print{*{box-shadow:none!important;text-shadow:none!important} | |
| html{font-size:80%} | |
| a{color:inherit!important;text-decoration:underline!important} | |
| a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important} | |
| a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em} | |
| abbr[title]{border-bottom:1px dotted} | |
| abbr[title]::after{content:" (" attr(title) ")"} | |
| pre,blockquote,tr,img,object,svg{page-break-inside:avoid} | |
| thead{display:table-header-group} | |
| svg{max-width:100%} | |
| p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3} | |
| h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid} | |
| #header,#content,#footnotes,#footer{max-width:none} | |
| #toc,.sidebarblock,.exampleblock>.content{background:none!important} | |
| #toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important} | |
| body.book #header{text-align:center} | |
| body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em} | |
| body.book #header .details{border:0!important;display:block;padding:0!important} | |
| body.book #header .details span:first-child{margin-left:0!important} | |
| body.book #header .details br{display:block} | |
| body.book #header .details br+span::before{content:none!important} | |
| body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important} | |
| body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always} | |
| .listingblock code[data-lang]::before{display:block} | |
| #footer{padding:0 .9375em} | |
| .hide-on-print{display:none!important} | |
| .print-only{display:block!important} | |
| .hide-for-print{display:none!important} | |
| .show-for-print{display:inherit!important}} | |
| @media amzn-kf8,print{#header>h1:first-child{margin-top:1.25rem} | |
| .sect1{padding:0!important} | |
| .sect1+.sect1{border:0} | |
| #footer{background:none} | |
| #footer-text{color:rgba(0,0,0,.6);font-size:.9em}} | |
| @media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}} | |
| </style> | |
| <style> | |
| pre>code { | |
| display: inline; | |
| } | |
| </style> | |
| </head> | |
| <body class="manpage"> | |
| <div id="header"> | |
| <h1>gitprotocol-v2(5) Manual Page</h1> | |
| <h2 id="_name">NAME</h2> | |
| <div class="sectionbody"> | |
| <p>gitprotocol-v2 - Git Wire Protocol, Version 2</p> | |
| </div> | |
| </div> | |
| <div id="content"> | |
| <div class="sect1"> | |
| <h2 id="_synopsis">SYNOPSIS</h2> | |
| <div class="sectionbody"> | |
| <div class="verseblock"> | |
| <pre class="content"><over-the-wire-protocol></pre> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_description">DESCRIPTION</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>This document presents a specification for a version 2 of Git’s wire | |
| protocol. Protocol v2 will improve upon v1 in the following ways:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>Instead of multiple service names, multiple commands will be | |
| supported by a single service</p> | |
| </li> | |
| <li> | |
| <p>Easily extendable as capabilities are moved into their own section | |
| of the protocol, no longer being hidden behind a NUL byte and | |
| limited by the size of a pkt-line</p> | |
| </li> | |
| <li> | |
| <p>Separate out other information hidden behind NUL bytes (e.g. agent | |
| string as a capability and symrefs can be requested using <em>ls-refs</em>)</p> | |
| </li> | |
| <li> | |
| <p>Reference advertisement will be omitted unless explicitly requested</p> | |
| </li> | |
| <li> | |
| <p>ls-refs command to explicitly request some refs</p> | |
| </li> | |
| <li> | |
| <p>Designed with http and stateless-rpc in mind. With clear flush | |
| semantics the http remote helper can simply act as a proxy</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In protocol v2 communication is command oriented. When first contacting a | |
| server a list of capabilities will be advertised. Some of these capabilities | |
| will be commands which a client can request be executed. Once a command | |
| has completed, a client can reuse the connection and request that other | |
| commands be executed.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_packet_line_framing">Packet-Line Framing</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>All communication is done using packet-line framing, just as in v1. See | |
| <a href="gitprotocol-pack.html">gitprotocol-pack(5)</a> and <a href="gitprotocol-common.html">gitprotocol-common(5)</a> for more information.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In protocol v2 these special packets will have the following semantics:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p><em>0000</em> Flush Packet (flush-pkt) - indicates the end of a message</p> | |
| </li> | |
| <li> | |
| <p><em>0001</em> Delimiter Packet (delim-pkt) - separates sections of a message</p> | |
| </li> | |
| <li> | |
| <p><em>0002</em> Response End Packet (response-end-pkt) - indicates the end of a | |
| response for stateless connections</p> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_initial_client_request">Initial Client Request</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>In general a client can request to speak protocol v2 by sending | |
| <code>version=2</code> through the respective side-channel for the transport being | |
| used which inevitably sets <code>GIT_PROTOCOL</code>. More information can be | |
| 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 | |
| <code>GIT_PROTOCOL</code> definition in <a href="git.html">git(1)</a>. In all cases the | |
| response from the server is the capability advertisement.</p> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_git_transport">Git Transport</h3> | |
| <div class="paragraph"> | |
| <p>When using the git:// transport, you can request to use protocol v2 by | |
| sending "version=2" as an extra parameter:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0</pre> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_ssh_and_file_transport">SSH and File Transport</h3> | |
| <div class="paragraph"> | |
| <p>When using either the ssh:// or file:// transport, the GIT_PROTOCOL | |
| environment variable must be set explicitly to include "version=2". | |
| The server may need to be configured to allow this environment variable | |
| to pass.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_http_transport">HTTP Transport</h3> | |
| <div class="paragraph"> | |
| <p>When using the http:// or https:// transport a client makes a "smart" | |
| info/refs request as described in <a href="gitprotocol-http.html">gitprotocol-http(5)</a> and requests that | |
| v2 be used by supplying "version=2" in the <code>Git-Protocol</code> header.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0 | |
| C: Git-Protocol: version=2</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>A v2 server would reply:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>S: 200 OK | |
| S: <Some headers> | |
| S: ... | |
| S: | |
| S: 000eversion 2\n | |
| S: <capability-advertisement></pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Subsequent requests are then made directly to the service | |
| <code>$GIT_URL/git-upload-pack</code>. (This works the same for git-receive-pack).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Uses the <code>--http-backend-info-refs</code> option to | |
| <a href="git-upload-pack.html">git-upload-pack(1)</a>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The server may need to be configured to pass this header’s contents via | |
| the <code>GIT_PROTOCOL</code> variable. See the discussion in <a href="git-http-backend.html">git-http-backend(1)</a>.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_capability_advertisement">Capability Advertisement</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>A server which decides to communicate (based on a request from a client) | |
| using protocol version 2, notifies the client by sending a version string | |
| in its initial response followed by an advertisement of its capabilities. | |
| Each capability is a key with an optional value. Clients must ignore all | |
| unknown keys. Semantics of unknown values are left to the definition of | |
| each key. Some capabilities will describe commands which can be requested | |
| to be executed by the client.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>capability-advertisement = protocol-version | |
| capability-list | |
| flush-pkt</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>protocol-version = PKT-LINE("version 2" LF) | |
| capability-list = *capability | |
| capability = PKT-LINE(key[=value] LF)</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>key = 1*(ALPHA | DIGIT | "-_") | |
| value = 1*(ALPHA | DIGIT | " -_.,?\/{}[]()<>!@#$%^&*+=:;")</pre> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_command_request">Command Request</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>After receiving the capability advertisement, a client can then issue a | |
| request to select the command it wants with any particular capabilities | |
| or arguments. There is then an optional section where the client can | |
| provide any command specific parameters or queries. Only a single | |
| command can be requested at a time.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>request = empty-request | command-request | |
| empty-request = flush-pkt | |
| command-request = command | |
| capability-list | |
| delim-pkt | |
| command-args | |
| flush-pkt | |
| command = PKT-LINE("command=" key LF) | |
| command-args = *command-specific-arg</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>command-specific-args are packet line framed arguments defined by | |
| each individual command.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The server will then check to ensure that the client’s request is | |
| comprised of a valid command as well as valid capabilities which were | |
| advertised. If the request is valid the server will then execute the | |
| command. A server MUST wait till it has received the client’s entire | |
| request before issuing a response. The format of the response is | |
| determined by the command being executed, but in all cases a flush-pkt | |
| indicates the end of the response.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>When a command has finished, and the client has received the entire | |
| response from the server, a client can either request that another | |
| command be executed or can terminate the connection. A client may | |
| optionally send an empty request consisting of just a flush-pkt to | |
| indicate that no more requests will be made.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_capabilities">Capabilities</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>There are two different types of capabilities: normal capabilities, | |
| which can be used to convey information or alter the behavior of a | |
| request, and commands, which are the core actions that a client wants to | |
| perform (fetch, push, etc).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Protocol version 2 is stateless by default. This means that all commands | |
| must only last a single round and be stateless from the perspective of the | |
| server side, unless the client has requested a capability indicating that | |
| state should be maintained by the server. Clients MUST NOT require state | |
| management on the server side in order to function correctly. This | |
| permits simple round-robin load-balancing on the server side, without | |
| needing to worry about state management.</p> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_agent">agent</h3> | |
| <div class="paragraph"> | |
| <p>The server can advertise the <code>agent</code> capability with a value <code>X</code> (in the | |
| form <code>agent=X</code>) to notify the client that the server is running version | |
| <code>X</code>. The client may optionally send its own agent string by including | |
| the <code>agent</code> capability with a value <code>Y</code> (in the form <code>agent=Y</code>) in its | |
| request to the server (but it MUST NOT do so if the server did not | |
| advertise the agent capability). The <code>X</code> and <code>Y</code> strings may contain any | |
| printable ASCII characters except space (i.e., the byte range 33 ⇐ x ⇐ | |
| 126), and are typically of the form "package/version-os" (e.g., | |
| "git/1.8.3.1-Linux") where <code>os</code> is the operating system name (e.g., | |
| "Linux"). <code>X</code> and <code>Y</code> can be configured using the GIT_USER_AGENT | |
| environment variable and it takes priority. The <code>os</code> is | |
| retrieved using the <em>sysname</em> field of the <code>uname</code>(<code>2</code>) system call | |
| or its equivalent. The agent strings are purely informative for statistics | |
| and debugging purposes, and MUST NOT be used to programmatically assume | |
| the presence or absence of particular features.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_ls_refs">ls-refs</h3> | |
| <div class="paragraph"> | |
| <p><code>ls-refs</code> is the command used to request a reference advertisement in v2. | |
| Unlike the current reference advertisement, ls-refs takes in arguments | |
| which can be used to limit the refs sent from the server.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Additional features not supported in the base command will be advertised | |
| as the value of the command in the capability advertisement in the form | |
| of a space separated list of features: "<command>=<feature-1> <feature-2>"</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>ls-refs takes in the following arguments:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> symrefs | |
| In addition to the object pointed by it, show the underlying ref | |
| pointed by it when showing a symbolic ref. | |
| peel | |
| Show peeled tags. | |
| ref-prefix <prefix> | |
| When specified, only references having a prefix matching one of | |
| the provided prefixes are displayed. Multiple instances may be | |
| given, in which case references matching any prefix will be | |
| shown. Note that this is purely for optimization; a server MAY | |
| show refs not matching the prefix if it chooses, and clients | |
| should filter the result themselves.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the <em>unborn</em> feature is advertised the following argument can be | |
| included in the client’s request.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> unborn | |
| The server will send information about HEAD even if it is a symref | |
| pointing to an unborn branch in the form "unborn HEAD | |
| symref-target:<target>".</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The output of ls-refs is as follows:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>output = *ref | |
| flush-pkt | |
| obj-id-or-unborn = (obj-id | "unborn") | |
| ref = PKT-LINE(obj-id-or-unborn SP refname *(SP ref-attribute) LF) | |
| ref-attribute = (symref | peeled) | |
| symref = "symref-target:" symref-target | |
| peeled = "peeled:" obj-id</pre> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_fetch">fetch</h3> | |
| <div class="paragraph"> | |
| <p><code>fetch</code> is the command used to fetch a packfile in v2. It can be looked | |
| at as a modified version of the v1 fetch where the ref-advertisement is | |
| stripped out (since the <code>ls-refs</code> command fills that role) and the | |
| message format is tweaked to eliminate redundancies and permit easy | |
| addition of future extensions.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Additional features not supported in the base command will be advertised | |
| as the value of the command in the capability advertisement in the form | |
| of a space separated list of features: "<command>=<feature-1> <feature-2>"</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>A <code>fetch</code> request can take the following arguments:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> want <oid> | |
| Indicates to the server an object which the client wants to | |
| retrieve. Wants can be anything and are not limited to | |
| advertised objects.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> have <oid> | |
| Indicates to the server an object which the client has locally. | |
| This allows the server to make a packfile which only contains | |
| the objects that the client needs. Multiple 'have' lines can be | |
| supplied.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> done | |
| Indicates to the server that negotiation should terminate (or | |
| not even begin if performing a clone) and that the server should | |
| use the information supplied in the request to construct the | |
| packfile.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> thin-pack | |
| Request that a thin pack be sent, which is a pack with deltas | |
| which reference base objects not contained within the pack (but | |
| are known to exist at the receiving end). This can reduce the | |
| network traffic significantly, but it requires the receiving end | |
| to know how to "thicken" these packs by adding the missing bases | |
| to the pack.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> no-progress | |
| Request that progress information that would normally be sent on | |
| side-band channel 2, during the packfile transfer, should not be | |
| sent. However, the side-band channel 3 is still used for error | |
| responses.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> include-tag | |
| Request that annotated tags should be sent if the objects they | |
| point to are being sent.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> ofs-delta | |
| Indicate that the client understands PACKv2 with delta referring | |
| to its base by position in pack rather than by an oid. That is, | |
| they can read OBJ_OFS_DELTA (aka type 6) in a packfile.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the <em>shallow</em> feature is advertised the following arguments can be | |
| included in the clients request as well as the potential addition of the | |
| <em>shallow-info</em> section in the server’s response as explained below.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> shallow <oid> | |
| A client must notify the server of all commits for which it only | |
| has shallow copies (meaning that it doesn't have the parents of | |
| a commit) by supplying a 'shallow <oid>' line for each such | |
| object so that the server is aware of the limitations of the | |
| client's history. This is so that the server is aware that the | |
| client may not have all objects reachable from such commits.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> deepen <depth> | |
| Requests that the fetch/clone should be shallow having a commit | |
| depth of <depth> relative to the remote side.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> deepen-relative | |
| Requests that the semantics of the "deepen" command be changed | |
| to indicate that the depth requested is relative to the client's | |
| current shallow boundary, instead of relative to the requested | |
| commits.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> deepen-since <timestamp> | |
| Requests that the shallow clone/fetch should be cut at a | |
| specific time, instead of depth. Internally it's equivalent to | |
| doing "git rev-list --max-age=<timestamp>". Cannot be used with | |
| "deepen".</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> deepen-not <rev> | |
| Requests that the shallow clone/fetch should be cut at a | |
| specific revision specified by '<rev>', instead of a depth. | |
| Internally it's equivalent of doing "git rev-list --not <rev>". | |
| Cannot be used with "deepen", but can be used with | |
| "deepen-since".</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the <em>filter</em> feature is advertised, the following argument can be | |
| included in the client’s request:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> filter <filter-spec> | |
| Request that various objects from the packfile be omitted | |
| using one of several filtering techniques. These are intended | |
| for use with partial clone and partial fetch operations. See | |
| `rev-list` for possible "filter-spec" values. When communicating | |
| with other processes, senders SHOULD translate scaled integers | |
| (e.g. "1k") into a fully-expanded form (e.g. "1024") to aid | |
| interoperability with older receivers that may not understand | |
| newly-invented scaling suffixes. However, receivers SHOULD | |
| accept the following suffixes: 'k', 'm', and 'g' for 1024, | |
| 1048576, and 1073741824, respectively.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the <em>ref-in-want</em> feature is advertised, the following argument can | |
| be included in the client’s request as well as the potential addition of | |
| the <em>wanted-refs</em> section in the server’s response as explained below.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> want-ref <ref> | |
| Indicates to the server that the client wants to retrieve a | |
| particular ref, where <ref> is the full name of a ref on the | |
| server. It is a protocol error to send want-ref for the | |
| same ref more than once.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the <em>sideband-all</em> feature is advertised, the following argument can be | |
| included in the client’s request:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> sideband-all | |
| Instruct the server to send the whole response multiplexed, not just | |
| the packfile section. All non-flush and non-delim PKT-LINE in the | |
| response (not only in the packfile section) will then start with a byte | |
| indicating its sideband (1, 2, or 3), and the server may send "0005\2" | |
| (a PKT-LINE of sideband 2 with no payload) as a keepalive packet.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the <em>packfile-uris</em> feature is advertised, the following argument | |
| can be included in the client’s request as well as the potential | |
| addition of the <em>packfile-uris</em> section in the server’s response as | |
| explained below. Note that at most one <code>packfile-uris</code> line can be sent | |
| to the server.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> packfile-uris <comma-separated-list-of-protocols> | |
| Indicates to the server that the client is willing to receive | |
| URIs of any of the given protocols in place of objects in the | |
| sent packfile. Before performing the connectivity check, the | |
| client should download from all given URIs. Currently, the | |
| protocols supported are "http" and "https".</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the <em>wait-for-done</em> feature is advertised, the following argument | |
| can be included in the client’s request.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> wait-for-done | |
| Indicates to the server that it should never send "ready", but | |
| should wait for the client to say "done" before sending the | |
| packfile.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The response of <code>fetch</code> is broken into a number of sections separated by | |
| delimiter packets (0001), with each section beginning with its section | |
| header. Most sections are sent only when the packfile is sent.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>output = acknowledgements flush-pkt | | |
| [acknowledgments delim-pkt] [shallow-info delim-pkt] | |
| [wanted-refs delim-pkt] [packfile-uris delim-pkt] | |
| packfile flush-pkt</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>acknowledgments = PKT-LINE("acknowledgments" LF) | |
| (nak | *ack) | |
| (ready) | |
| ready = PKT-LINE("ready" LF) | |
| nak = PKT-LINE("NAK" LF) | |
| ack = PKT-LINE("ACK" SP obj-id LF)</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>shallow-info = PKT-LINE("shallow-info" LF) | |
| *PKT-LINE((shallow | unshallow) LF) | |
| shallow = "shallow" SP obj-id | |
| unshallow = "unshallow" SP obj-id</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>wanted-refs = PKT-LINE("wanted-refs" LF) | |
| *PKT-LINE(wanted-ref LF) | |
| wanted-ref = obj-id SP refname</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>packfile-uris = PKT-LINE("packfile-uris" LF) *packfile-uri | |
| packfile-uri = PKT-LINE(40*(HEXDIGIT) SP *%x20-ff LF)</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>packfile = PKT-LINE("packfile" LF) | |
| *PKT-LINE(%x01-03 *%x00-ff)</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> acknowledgments section | |
| * If the client determines that it is finished with negotiations by | |
| sending a "done" line (thus requiring the server to send a packfile), | |
| the acknowledgments sections MUST be omitted from the server's | |
| response.</pre> | |
| </div> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>Always begins with the section header "acknowledgments"</p> | |
| </li> | |
| <li> | |
| <p>The server will respond with "NAK" if none of the object ids sent | |
| as have lines were common.</p> | |
| </li> | |
| <li> | |
| <p>The server will respond with "ACK obj-id" for all of the | |
| object ids sent as have lines which are common.</p> | |
| </li> | |
| <li> | |
| <p>A response cannot have both "ACK" lines as well as a "NAK" | |
| line.</p> | |
| </li> | |
| <li> | |
| <p>The server will respond with a "ready" line indicating that | |
| the server has found an acceptable common base and is ready to | |
| make and send a packfile (which will be found in the packfile | |
| section of the same response)</p> | |
| </li> | |
| <li> | |
| <p>If the server has found a suitable cut point and has decided | |
| to send a "ready" line, then the server can decide to (as an | |
| optimization) omit any "ACK" lines it would have sent during | |
| its response. This is because the server will have already | |
| determined the objects it plans to send to the client and no | |
| further negotiation is needed.</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> shallow-info section | |
| * If the client has requested a shallow fetch/clone, a shallow | |
| client requests a fetch or the server is shallow then the | |
| server's response may include a shallow-info section. The | |
| shallow-info section will be included if (due to one of the | |
| above conditions) the server needs to inform the client of any | |
| shallow boundaries or adjustments to the clients already | |
| existing shallow boundaries.</pre> | |
| </div> | |
| </div> | |
| </li> | |
| <li> | |
| <p>Always begins with the section header "shallow-info"</p> | |
| </li> | |
| <li> | |
| <p>If a positive depth is requested, the server will compute the | |
| set of commits which are no deeper than the desired depth.</p> | |
| </li> | |
| <li> | |
| <p>The server sends a "shallow obj-id" line for each commit whose | |
| parents will not be sent in the following packfile.</p> | |
| </li> | |
| <li> | |
| <p>The server sends an "unshallow obj-id" line for each commit | |
| which the client has indicated is shallow, but is no longer | |
| shallow as a result of the fetch (due to its parents being | |
| sent in the following packfile).</p> | |
| </li> | |
| <li> | |
| <p>The server MUST NOT send any "unshallow" lines for anything | |
| which the client has not indicated was shallow as a part of | |
| its request.</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> wanted-refs section | |
| * This section is only included if the client has requested a | |
| ref using a 'want-ref' line and if a packfile section is also | |
| included in the response.</pre> | |
| </div> | |
| </div> | |
| </li> | |
| <li> | |
| <p>Always begins with the section header "wanted-refs".</p> | |
| </li> | |
| <li> | |
| <p>The server will send a ref listing ("<oid> <refname>") for | |
| each reference requested using <em>want-ref</em> lines.</p> | |
| </li> | |
| <li> | |
| <p>The server MUST NOT send any refs which were not requested | |
| using <em>want-ref</em> lines.</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> packfile-uris section | |
| * This section is only included if the client sent | |
| 'packfile-uris' and the server has at least one such URI to | |
| send.</pre> | |
| </div> | |
| </div> | |
| </li> | |
| <li> | |
| <p>Always begins with the section header "packfile-uris".</p> | |
| </li> | |
| <li> | |
| <p>For each URI the server sends, it sends a hash of the pack’s | |
| contents (as output by git index-pack) followed by the URI.</p> | |
| </li> | |
| <li> | |
| <p>The hashes are 40 hex characters long. When Git upgrades to a new | |
| hash algorithm, this might need to be updated. (It should match | |
| whatever index-pack outputs after "pack\t" or "keep\t".</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> packfile section | |
| * This section is only included if the client has sent 'want' | |
| lines in its request and either requested that no more | |
| negotiation be done by sending 'done' or if the server has | |
| decided it has found a sufficient cut point to produce a | |
| packfile.</pre> | |
| </div> | |
| </div> | |
| </li> | |
| <li> | |
| <p>Always begins with the section header "packfile"</p> | |
| </li> | |
| <li> | |
| <p>The transmission of the packfile begins immediately after the | |
| section header</p> | |
| </li> | |
| <li> | |
| <p>The data transfer of the packfile is always multiplexed, using | |
| the same semantics of the <em>side-band-64k</em> capability from | |
| protocol version 1. This means that each packet, during the | |
| packfile data stream, is made up of a leading 4-byte pkt-line | |
| length (typical of the pkt-line format), followed by a 1-byte | |
| stream code, followed by the actual data.</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> The stream code can be one of: | |
| 1 - pack data | |
| 2 - progress messages | |
| 3 - fatal error message just before stream aborts</pre> | |
| </div> | |
| </div> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_server_option">server-option</h3> | |
| <div class="paragraph"> | |
| <p>If advertised, indicates that any number of server specific options can be | |
| included in a request. This is done by sending each option as a | |
| "server-option=<option>" capability line in the capability-list section of | |
| a request.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The provided options must not contain a NUL or LF character.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_object_format">object-format</h3> | |
| <div class="paragraph"> | |
| <p>The server can advertise the <code>object-format</code> capability with a value <code>X</code> (in the | |
| form <code>object-format=X</code>) to notify the client that the server is able to deal | |
| with objects using hash algorithm X. If not specified, the server is assumed to | |
| only handle SHA-1. If the client would like to use a hash algorithm other than | |
| SHA-1, it should specify its object-format string.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_session_idsession_id">session-id=<session-id></h3> | |
| <div class="paragraph"> | |
| <p>The server may advertise a session ID that can be used to identify this process | |
| across multiple requests. The client may advertise its own session ID back to | |
| the server as well.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Session IDs should be unique to a given process. They must fit within a | |
| packet-line, and must not contain non-printable or whitespace characters. The | |
| current implementation uses trace2 session IDs (see | |
| <a href="technical/api-trace2.html">api-trace2</a> for details), but this may change | |
| and users of the session ID should not rely on this fact.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_object_info">object-info</h3> | |
| <div class="paragraph"> | |
| <p><code>object-info</code> is the command to retrieve information about one or more objects. | |
| Its main purpose is to allow a client to make decisions based on this | |
| information without having to fully fetch objects. Object size is the only | |
| information that is currently supported.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>An <code>object-info</code> request takes the following arguments:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>size | |
| Requests size information to be returned for each listed object id.</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>oid <oid> | |
| Indicates to the server an object which the client wants to obtain | |
| information for.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The response of <code>object-info</code> is a list of the requested object ids | |
| and associated requested information, each separated by a single space.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>output = info flush-pkt</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>info = PKT-LINE(attrs) LF) | |
| *PKT-LINE(obj-info LF)</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>attrs = attr | attrs SP attrs</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>attr = "size"</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>obj-info = obj-id SP obj-size</pre> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_bundle_uri">bundle-uri</h3> | |
| <div class="paragraph"> | |
| <p>If the <em>bundle-uri</em> capability is advertised, the server supports the | |
| ‘bundle-uri’ command.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The capability is currently advertised with no value (i.e. not | |
| "bundle-uri=somevalue"), a value may be added in the future for | |
| supporting command-wide extensions. Clients MUST ignore any unknown | |
| capability values and proceed with the 'bundle-uri` dialog they | |
| support.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The <em>bundle-uri</em> command is intended to be issued before <code>fetch</code> to | |
| get URIs to bundle files (see <a href="git-bundle.html">git-bundle(1)</a>) to "seed" and | |
| inform the subsequent <code>fetch</code> command.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The client CAN issue <code>bundle-uri</code> before or after any other valid | |
| command. To be useful to clients it’s expected that it’ll be issued | |
| after an <code>ls-refs</code> and before <code>fetch</code>, but CAN be issued at any time | |
| in the dialog.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_discussion_of_bundle_uri">DISCUSSION of bundle-uri</h4> | |
| <div class="paragraph"> | |
| <p>The intent of the feature is optimize for server resource consumption | |
| in the common case by changing the common case of fetching a very | |
| large PACK during <a href="git-clone.html">git-clone(1)</a> into a smaller incremental | |
| fetch.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>It also allows servers to achieve better caching in combination with | |
| an <code>uploadpack.packObjectsHook</code> (see <a href="git-config.html">git-config(1)</a>).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>By having new clones or fetches be a more predictable and common | |
| negotiation against the tips of recently produces *.bundle file(s). | |
| Servers might even pre-generate the results of such negotiations for | |
| the <code>uploadpack.packObjectsHook</code> as new pushes come in.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>One way that servers could take advantage of these bundles is that the | |
| server would anticipate that fresh clones will download a known bundle, | |
| followed by catching up to the current state of the repository using ref | |
| tips found in that bundle (or bundles).</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_protocol_for_bundle_uri">PROTOCOL for bundle-uri</h4> | |
| <div class="paragraph"> | |
| <p>A <code>bundle-uri</code> request takes no arguments, and as noted above does not | |
| currently advertise a capability value. Both may be added in the | |
| future.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>When the client issues a <code>command=bundle-uri</code> request, the response is a | |
| list of key-value pairs provided as packet lines with value | |
| <em><key></em><code>=</code><em><value></em>. Each <em><key></em> should be interpreted as a config key from | |
| the <code>bundle.*</code> namespace to construct a list of bundles. These keys are | |
| grouped by a <code>bundle.</code><em><id></em>. subsection, where each key corresponding to a | |
| given <em><id></em> contributes attributes to the bundle defined by that <em><id></em>. | |
| See <a href="git-config.html">git-config(1)</a> for the specific details of these keys and how | |
| the Git client will interpret their values.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Clients MUST parse the line according to the above format, lines that do | |
| not conform to the format SHOULD be discarded. The user MAY be warned in | |
| such a case.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_bundle_uri_client_and_server_expectations">bundle-uri CLIENT AND SERVER EXPECTATIONS</h4> | |
| <div class="dlist"> | |
| <dl> | |
| <dt class="hdlist1">URI CONTENTS</dt> | |
| <dd> | |
| <p>The content at the advertised URIs MUST be one of two types.</p> | |
| <div class="paragraph"> | |
| <p>The advertised URI may contain a bundle file that <code>git</code> <code>bundle</code> <code>verify</code> | |
| would accept. I.e. they MUST contain one or more reference tips for | |
| use by the client, MUST indicate prerequisites (in any) with standard | |
| "-" prefixes, and MUST indicate their "object-format", if | |
| applicable.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The advertised URI may alternatively contain a plaintext file that <code>git</code> | |
| <code>config</code> <code>list</code> would accept (with the <code>--file</code> option). The key-value | |
| pairs in this list are in the <code>bundle.*</code> namespace (see | |
| <a href="git-config.html">git-config(1)</a>).</p> | |
| </div> | |
| </dd> | |
| <dt class="hdlist1">bundle-uri CLIENT ERROR RECOVERY</dt> | |
| <dd> | |
| <p>A client MUST above all gracefully degrade on errors, whether that | |
| error is because of bad missing/data in the bundle URI(s), because | |
| that client is too dumb to e.g. understand and fully parse out bundle | |
| headers and their prerequisite relationships, or something else.</p> | |
| <div class="paragraph"> | |
| <p>Server operators should feel confident in turning on "bundle-uri" and | |
| not worry if e.g. their CDN goes down that clones or fetches will run | |
| into hard failures. Even if the server bundle(s) are | |
| incomplete, or bad in some way the client should still end up with a | |
| functioning repository, just as if it had chosen not to use this | |
| protocol extension.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>All subsequent discussion on client and server interaction MUST keep | |
| this in mind.</p> | |
| </div> | |
| </dd> | |
| <dt class="hdlist1">bundle-uri SERVER TO CLIENT</dt> | |
| <dd> | |
| <p>The ordering of the returned bundle uris is not significant. Clients | |
| MUST parse their headers to discover their contained OIDS and | |
| prerequisites. A client MUST consider the content of the bundle(s) | |
| themselves and their header as the ultimate source of truth.</p> | |
| <div class="paragraph"> | |
| <p>A server MAY even return bundle(s) that don’t have any direct | |
| relationship to the repository being cloned (either through accident, | |
| or intentional "clever" configuration), and expect a client to sort | |
| out what data they’d like from the bundle(s), if any.</p> | |
| </div> | |
| </dd> | |
| <dt class="hdlist1">bundle-uri CLIENT TO SERVER</dt> | |
| <dd> | |
| <p>The client SHOULD provide reference tips found in the bundle header(s) | |
| as <em>have</em> lines in any subsequent <code>fetch</code> request. A client MAY also | |
| ignore the bundle(s) entirely if doing so is deemed worse for some | |
| reason, e.g. if the bundles can’t be downloaded, it doesn’t like the | |
| tips it finds etc.</p> | |
| </dd> | |
| <dt class="hdlist1">WHEN ADVERTISED BUNDLE(S) REQUIRE NO FURTHER NEGOTIATION</dt> | |
| <dd> | |
| <p>If after issuing <code>bundle-uri</code> and <code>ls-refs</code>, and getting the header(s) | |
| of the bundle(s) the client finds that the ref tips it wants can be | |
| retrieved entirely from advertised bundle(s), the client MAY disconnect | |
| from the Git server. The results of such a <em>clone</em> or <em>fetch</em> should be | |
| indistinguishable from the state attained without using bundle-uri.</p> | |
| </dd> | |
| <dt class="hdlist1">EARLY CLIENT DISCONNECTIONS AND ERROR RECOVERY</dt> | |
| <dd> | |
| <p>A client MAY perform an early disconnect while still downloading the | |
| bundle(s) (having streamed and parsed their headers). In such a case | |
| the client MUST gracefully recover from any errors related to | |
| finishing the download and validation of the bundle(s).</p> | |
| <div class="paragraph"> | |
| <p>I.e. a client might need to re-connect and issue a <em>fetch</em> command, | |
| and possibly fall back to not making use of <em>bundle-uri</em> at all.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This "MAY" behavior is specified as such (and not a "SHOULD") on the | |
| assumption that a server advertising bundle uris is more likely than | |
| not to be serving up a relatively large repository, and to be pointing | |
| to URIs that have a good chance of being in working order. A client | |
| MAY e.g. look at the payload size of the bundles as a heuristic to see | |
| if an early disconnect is worth it, should falling back on a full | |
| "fetch" dialog be necessary.</p> | |
| </div> | |
| </dd> | |
| <dt class="hdlist1">WHEN ADVERTISED BUNDLE(S) REQUIRE FURTHER NEGOTIATION</dt> | |
| <dd> | |
| <p>A client SHOULD commence a negotiation of a PACK from the server via | |
| the "fetch" command using the OID tips found in advertised bundles, | |
| even if’s still in the process of downloading those bundle(s).</p> | |
| <div class="paragraph"> | |
| <p>This allows for aggressive early disconnects from any interactive | |
| server dialog. The client blindly trusts that the advertised OID tips | |
| are relevant, and issues them as <em>have</em> lines, it then requests any | |
| tips it would like (usually from the "ls-refs" advertisement) via | |
| <em>want</em> lines. The server will then compute a (hopefully small) PACK | |
| with the expected difference between the tips from the bundle(s) and | |
| the data requested.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The only connection the client then needs to keep active is to the | |
| concurrently downloading static bundle(s), when those and the | |
| incremental PACK are retrieved they should be inflated and | |
| validated. Any errors at this point should be gracefully recovered | |
| from, see above.</p> | |
| </div> | |
| </dd> | |
| </dl> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_bundle_uri_protocol_features">bundle-uri PROTOCOL FEATURES</h4> | |
| <div class="paragraph"> | |
| <p>The client constructs a bundle list from the <em><key></em><code>=</code><em><value></em> pairs | |
| provided by the server. These pairs are part of the <code>bundle.*</code> namespace | |
| as documented in <a href="git-config.html">git-config(1)</a>. In this section, we discuss some | |
| of these keys and describe the actions the client will do in response to | |
| this information.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In particular, the <code>bundle.version</code> key specifies an integer value. The | |
| only accepted value at the moment is <code>1</code>, but if the client sees an | |
| unexpected value here then the client MUST ignore the bundle list.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>As long as <code>bundle.version</code> is understood, all other unknown keys MAY be | |
| ignored by the client. The server will guarantee compatibility with older | |
| clients, though newer clients may be better able to use the extra keys to | |
| minimize downloads.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Any backwards-incompatible addition of pre-URI key-value will be | |
| guarded by a new <code>bundle.version</code> value or values in <em>bundle-uri</em> | |
| capability advertisement itself, and/or by new future <code>bundle-uri</code> | |
| request arguments.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Some example key-value pairs that are not currently implemented but could | |
| be implemented in the future include:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>Add a "hash=<val>" or "size=<bytes>" advertise the expected hash or | |
| size of the bundle file.</p> | |
| </li> | |
| <li> | |
| <p>Advertise that one or more bundle files are the same (to e.g. have | |
| clients round-robin or otherwise choose one of N possible files).</p> | |
| </li> | |
| <li> | |
| <p>A "oid=<OID>" shortcut and "prerequisite=<OID>" shortcut. For | |
| expressing the common case of a bundle with one tip and no | |
| prerequisites, or one tip and one prerequisite.</p> | |
| <div class="paragraph"> | |
| <p>This would allow for optimizing the common case of servers who’d like | |
| to provide one "big bundle" containing only their "main" branch, | |
| and/or incremental updates thereof.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>A client receiving such a response MAY assume that they can skip | |
| retrieving the header from a bundle at the indicated URI, and thus | |
| save themselves and the server(s) the request(s) needed to inspect the | |
| headers of that bundle or bundles.</p> | |
| </div> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_promisor_remotepr_info">promisor-remote=<pr-info></h3> | |
| <div class="paragraph"> | |
| <p>The server may advertise some promisor remotes it is using or knows | |
| about to a client which may want to use them as its promisor remotes, | |
| instead of this repository. In this case <pr-info> should be of the | |
| form:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>pr-info = pr-fields | pr-info ";" pr-fields</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>pr-fields = pr-field | pr-fields "," pr-field</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>pr-field = field-name "=" field-value</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>where all the <code>field-name</code> and <code>field-value</code> in a given <code>pr-fields</code> | |
| are field names and values related to a single promisor remote. A | |
| given <code>field-name</code> MUST NOT appear more than once in given | |
| <code>pr-fields</code>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The server MUST advertise at least the "name" and "url" field names | |
| along with the associated field values, which are the name of a valid | |
| remote and its URL, in each <code>pr-fields</code>. The "name" and "url" fields | |
| MUST appear first in each pr-fields, in that order.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>After these mandatory fields, the server MAY advertise the following | |
| optional fields in any order:</p> | |
| </div> | |
| <div class="dlist"> | |
| <dl> | |
| <dt class="hdlist1"><code>partialCloneFilter</code></dt> | |
| <dd> | |
| <p>The filter specification for the remote. It | |
| corresponds to the "remote.<name>.partialCloneFilter" config setting. | |
| Clients can use this to determine if the remote’s filtering strategy | |
| is compatible with their needs (e.g., checking if both use | |
| "blob:none"). Additionally they can use this through the | |
| <code>--filter=auto</code> option in <a href="git-clone.html">git-clone(1)</a>. With that option, the | |
| filter specification of the clone will be automatically computed by | |
| combining the filter specifications of the promisor remotes the client | |
| accepts.</p> | |
| </dd> | |
| <dt class="hdlist1"><code>token</code></dt> | |
| <dd> | |
| <p>An authentication token that clients can use when | |
| connecting to the remote. It corresponds to the "remote.<name>.token" | |
| config setting.</p> | |
| </dd> | |
| </dl> | |
| </div> | |
| <div class="paragraph"> | |
| <p>No other fields are defined by the protocol at this time. Field names | |
| are case-sensitive and MUST be transmitted exactly as specified | |
| above. Clients MUST ignore fields they don’t recognize to allow for | |
| future protocol extensions.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The client can use information transmitted through these fields to | |
| decide if it accepts the advertised promisor remote. Also, the client | |
| can be configured to store the values of these fields or use them | |
| to automatically configure the repository (see "promisor.storeFields" | |
| in <a href="git-config.html">git-config(1)</a> and <code>--filter=auto</code> in <a href="git-clone.html">git-clone(1)</a>).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Field values MUST be urlencoded.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the client decides to use one or more promisor remotes the server | |
| advertised, it can reply with "promisor-remote=<pr-names>" where | |
| <pr-names> should be of the form:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>pr-names = pr-name | pr-names ";" pr-name</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>where <code>pr-name</code> is the urlencoded name of a promisor remote the server | |
| advertised and the client accepts.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The promisor remotes that the client accepted will be tried before the | |
| other configured promisor remotes when the client attempts to fetch | |
| missing objects.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Note that, everywhere in this document, the <em>;</em> and <em>,</em> characters | |
| MUST be encoded if they appear in <code>pr-name</code> or <code>field-value</code>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If the server doesn’t know any promisor remote that could be good for | |
| a client to use, or prefers a client not to use any promisor remote it | |
| uses or knows about, it shouldn’t advertise the "promisor-remote" | |
| capability at all.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In this case, or if the client doesn’t want to use any promisor remote | |
| the server advertised, the client shouldn’t advertise the | |
| "promisor-remote" capability at all in its reply.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>On the server side, the "promisor.advertise" and "promisor.sendFields" | |
| configuration options can be used to control what it advertises. On | |
| the client side, the "promisor.acceptFromServer" and | |
| "promisor.acceptFromServerUrl" configuration options can be used to | |
| control what it accepts, and the "promisor.storeFields" option, to | |
| control what it stores. See the documentation of these configuration | |
| options in <a href="git-config.html">git-config(1)</a> for more information.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Note that in the future it would be nice if the "promisor-remote" | |
| protocol capability could be used by the server, when responding to | |
| <code>git</code> <code>fetch</code> or <code>git</code> <code>clone</code>, to advertise better-connected remotes that | |
| the client can use as promisor remotes, instead of this repository, so | |
| that the client can lazily fetch objects from these other | |
| better-connected remotes. This would require the server to omit in its | |
| response the objects available on the better-connected remotes that | |
| the client has accepted. This hasn’t been implemented yet though. So | |
| for now this "promisor-remote" capability is useful only when the | |
| server advertises some promisor remotes it already uses to borrow | |
| objects from.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_git">GIT</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>Part of the <a href="git.html">git(1)</a> suite</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated 2026-07-06 18:29:57 -0700 | |
| </div> | |
| </div> | |
| </body> | |
| </html> |