| <!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>Large Object Promisors</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> | |
| </head> | |
| <body class="article"> | |
| <div id="header"> | |
| <h1>Large Object Promisors</h1> | |
| </div> | |
| <div id="content"> | |
| <div id="preamble"> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>Since Git has been created, users have been complaining about issues | |
| with storing large files in Git. Some solutions have been created to | |
| help, but they haven’t helped much with some issues.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Git currently supports multiple promisor remotes, which could help | |
| with some of these remaining issues, but it’s very hard to use them to | |
| help, because a number of important features are missing.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The goal of the effort described in this document is to add these | |
| important features.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>We will call a "Large Object Promisor", or "LOP" in short, a promisor | |
| remote which is used to store only large blobs and which is separate | |
| from the main remote that should store the other Git objects and the | |
| rest of the repos.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>By extension, we will also call "Large Object Promisor", or LOP, the | |
| effort described in this document to add a set of features to make it | |
| easier to handle large blobs/files in Git by using LOPs.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This effort aims to especially improve things on the server side, and | |
| especially for large blobs that are already compressed in a binary | |
| format.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This effort aims to provide an alternative to Git LFS | |
| (<a href="https://git-lfs.com/" class="bare">https://git-lfs.com/</a>) and similar tools like git-annex | |
| (<a href="https://git-annex.branchable.com/" class="bare">https://git-annex.branchable.com/</a>) for handling large files, even | |
| though a complete alternative would very likely require other efforts | |
| especially on the client side, where it would likely help to implement | |
| a new object representation for large blobs as discussed in:</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p><a href="https://lore.kernel.org/git/xmqqbkdometi.fsf@gitster.g/" class="bare">https://lore.kernel.org/git/xmqqbkdometi.fsf@gitster.g/</a></p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_non_goals">Non goals</h2> | |
| <div class="sectionbody"> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>We will not discuss those client side improvements here, as they | |
| would require changes in different parts of Git than this effort.</p> | |
| <div class="paragraph"> | |
| <p>So we don’t pretend to fully replace Git LFS with only this effort, | |
| but we nevertheless believe that it can significantly improve the | |
| current situation on the server side, and that other separate | |
| efforts could also improve the situation on the client side.</p> | |
| </div> | |
| </li> | |
| <li> | |
| <p>In the same way, we are not going to discuss all the possible ways | |
| to implement a LOP or their underlying object storage, or to | |
| optimize how LOP works.</p> | |
| <div class="paragraph"> | |
| <p>Our opinion is that the simplest solution for now is for LOPs to use | |
| object storage through a remote helper (see section II.2 below for | |
| more details) to store their objects. So we consider that this is the | |
| default implementation. If there are improvements on top of this, | |
| that’s great, but our opinion is that such improvements are not | |
| necessary for LOPs to already be useful. Such improvements are likely | |
| a different technical topic, and can be taken care of separately | |
| anyway.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>So in particular we are not going to discuss pluggable ODBs or other | |
| object database backends that could chunk large blobs, dedup the | |
| chunks and store them efficiently. Sure, that would be a nice | |
| improvement to store large blobs on the server side, but we believe | |
| it can just be a separate effort as it’s also not technically very | |
| related to this effort.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>We are also not going to discuss data transfer improvements between | |
| LOPs and clients or servers. Sure, there might be some easy and very | |
| effective optimizations there (as we know that objects on LOPs are | |
| very likely incompressible and not deltifying well), but this can be | |
| dealt with separately in a separate effort.</p> | |
| </div> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In other words, the goal of this document is not to talk about all the | |
| possible ways to optimize how Git could handle large blobs, but to | |
| describe how a LOP based solution can already work well and alleviate | |
| a number of current issues in the context of Git clients and servers | |
| sharing Git objects.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Even if LOPs are used not very efficiently, they can still be useful | |
| and worth using in some cases, as we will see in more details | |
| later in this document:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>they can make it simpler for clients to use promisor remotes and | |
| therefore avoid fetching a lot of large blobs they might not need | |
| locally,</p> | |
| </li> | |
| <li> | |
| <p>they can make it significantly cheaper or easier for servers to | |
| host a significant part of the current repository content, and | |
| even more to host content with larger blobs or more large blobs | |
| than currently.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_i_issues_with_the_current_situation">I Issues with the current situation</h2> | |
| <div class="sectionbody"> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>Some statistics made on GitLab repos have shown that more than 75% | |
| of the disk space is used by blobs that are larger than 1MB and | |
| often in a binary format.</p> | |
| </li> | |
| <li> | |
| <p>So even if users could use Git LFS or similar tools to store a lot | |
| of large blobs out of their repos, it’s a fact that in practice they | |
| don’t do it as much as they probably should.</p> | |
| </li> | |
| <li> | |
| <p>On the server side ideally, the server should be able to decide for | |
| itself how it stores things. It should not depend on users deciding | |
| to use tools like Git LFS on some blobs or not.</p> | |
| </li> | |
| <li> | |
| <p>It’s much more expensive to store large blobs that don’t delta | |
| compress well on regular fast seeking drives (like SSDs) than on | |
| object storage (like Amazon S3 or GCP Buckets). Using fast drives | |
| for regular Git repos makes sense though, as serving regular Git | |
| content (blobs containing text or code) needs drives where seeking | |
| is fast, but the content is relatively small. On the other hand, | |
| object storage for Git LFS blobs makes sense as seeking speed is not | |
| as important when dealing with large files, while costs are more | |
| important. So the fact that users don’t use Git LFS or similar tools | |
| for a significant number of large blobs has likely some bad | |
| consequences on the cost of repo storage for most Git hosting | |
| platforms.</p> | |
| </li> | |
| <li> | |
| <p>Having large blobs handled in the same way as other blobs and Git | |
| objects in Git repos instead of on object storage also has a cost in | |
| increased memory and CPU usage, and therefore decreased performance, | |
| when creating packfiles. (This is because Git tries to use delta | |
| compression or zlib compression which is unlikely to work well on | |
| already compressed binary content.) So it’s not just a storage cost | |
| increase.</p> | |
| </li> | |
| <li> | |
| <p>When a large blob has been committed into a repo, it might not be | |
| possible to remove this blob from the repo without rewriting | |
| history, even if the user then decides to use Git LFS or a similar | |
| tool to handle it.</p> | |
| </li> | |
| <li> | |
| <p>In fact Git LFS and similar tools are not very flexible in letting | |
| users change their minds about the blobs they should handle or not.</p> | |
| </li> | |
| <li> | |
| <p>Even when users are using Git LFS or similar tools, they are often | |
| complaining that these tools require significant effort to set up, | |
| learn and use correctly.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_ii_main_features_of_the_large_object_promisors_solution">II Main features of the "Large Object Promisors" solution</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>The main features below should give a rough overview of how the | |
| solution may work. Details about needed elements can be found in | |
| following sections.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Even if each feature below is very useful for the full solution, it is | |
| very likely to be also useful on its own in some cases where the full | |
| solution is not required. However, we’ll focus primarily on the big | |
| picture here.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Also each feature doesn’t need to be implemented entirely in Git | |
| itself. Some could be scripts, hooks or helpers that are not part of | |
| the Git repo. It would be helpful if those could be shared and | |
| improved on collaboratively though. So we want to encourage sharing | |
| them.</p> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_1_large_blobs_are_stored_on_lops">1) Large blobs are stored on LOPs</h3> | |
| <div class="paragraph"> | |
| <p>Large blobs should be stored on special promisor remotes that we will | |
| call "Large Object Promisors" or LOPs. These LOPs should be additional | |
| remotes dedicated to contain large blobs especially those in binary | |
| format. They should be used along with main remotes that contain the | |
| other objects.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_note_1">Note 1</h4> | |
| <div class="paragraph"> | |
| <p>To clarify, a LOP is a normal promisor remote, except that:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>it should store only large blobs,</p> | |
| </li> | |
| <li> | |
| <p>it should be separate from the main remote, so that the main remote | |
| can focus on serving other objects and the rest of the repos (see | |
| feature 4) below) and can use the LOP as a promisor remote for | |
| itself.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_note_2">Note 2</h4> | |
| <div class="paragraph"> | |
| <p>Git already makes it possible for a main remote to also be a promisor | |
| remote storing both regular objects and large blobs for a client that | |
| clones from it with a filter on blob size. But here we explicitly want | |
| to avoid that.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_rationale">Rationale</h4> | |
| <div class="paragraph"> | |
| <p>LOPs aim to be good at handling large blobs while main remotes are | |
| already good at handling other objects.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_implementation">Implementation</h4> | |
| <div class="paragraph"> | |
| <p>Git already has support for multiple promisor remotes, see | |
| <a href="partial-clone.html#using-many-promisor-remotes">the partial clone documentation</a>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Also, Git already has support for partial clone using a filter on the | |
| size of the blobs (with <code>git</code> <code>clone</code> <code>--filter=blob:limit=</code><em><size></em>). Most | |
| of the other main features below are based on these existing features | |
| and are about making them easy and efficient to use for the purpose of | |
| better handling large blobs.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_2_lops_can_use_object_storage">2) LOPs can use object storage</h3> | |
| <div class="paragraph"> | |
| <p>LOPs can be implemented using object storage, like an Amazon S3 or GCP | |
| Bucket or MinIO (which is open source under the GNU AGPLv3 license) to | |
| actually store the large blobs, and can be accessed through a Git | |
| remote helper (see <a href="../gitremote-helpers.html">gitremote-helpers(7)</a>) which makes the | |
| underlying object storage appear like a remote to Git.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_note">Note</h4> | |
| <div class="paragraph"> | |
| <p>A LOP can be a promisor remote accessed using a remote helper by | |
| both some clients and the main remote.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_rationale_2">Rationale</h4> | |
| <div class="paragraph"> | |
| <p>This looks like the simplest way to create LOPs that can cheaply | |
| handle many large blobs.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_implementation_2">Implementation</h4> | |
| <div class="paragraph"> | |
| <p>Remote helpers are quite easy to write as shell scripts, but it might | |
| be more efficient and maintainable to write them using other languages | |
| like Go.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Some already exist under open source licenses, for example:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p><a href="https://github.com/awslabs/git-remote-s3" class="bare">https://github.com/awslabs/git-remote-s3</a></p> | |
| </li> | |
| <li> | |
| <p><a href="https://gitlab.com/eric.p.ju/git-remote-gs" class="bare">https://gitlab.com/eric.p.ju/git-remote-gs</a></p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Other ways to implement LOPs are certainly possible, but the goal of | |
| this document is not to discuss how to best implement a LOP or its | |
| underlying object storage (see the "0) Non goals" section above).</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_3_lop_object_storage_can_be_git_lfs_storage">3) LOP object storage can be Git LFS storage</h3> | |
| <div class="paragraph"> | |
| <p>The underlying object storage that a LOP uses could also serve as | |
| storage for large files handled by Git LFS.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_rationale_3">Rationale</h4> | |
| <div class="paragraph"> | |
| <p>This would simplify the server side if it wants to both use a LOP and | |
| act as a Git LFS server.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_4_a_main_remote_can_offload_to_a_lop_with_a_configurable_threshold">4) A main remote can offload to a LOP with a configurable threshold</h3> | |
| <div class="paragraph"> | |
| <p>On the server side, a main remote should have a way to offload to a | |
| LOP all its blobs with a size over a configurable threshold.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_rationale_4">Rationale</h4> | |
| <div class="paragraph"> | |
| <p>This makes it easy to set things up and to clean things up. For | |
| example, an admin could use this to manually convert a repo not using | |
| LOPs to a repo using a LOP. On a repo already using a LOP but where | |
| some users would sometimes push large blobs, a cron job could use this | |
| to regularly make sure the large blobs are moved to the LOP.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_implementation_3">Implementation</h4> | |
| <div class="paragraph"> | |
| <p>Using something based on <code>git</code> <code>repack</code> <code>--filter=..</code>. to separate the | |
| blobs we want to offload from the other Git objects could be a good | |
| idea. The missing part is to connect to the LOP, check if the blobs we | |
| want to offload are already there and if not send them.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_5_a_main_remote_should_try_to_remain_clean_from_large_blobs">5) A main remote should try to remain clean from large blobs</h3> | |
| <div class="paragraph"> | |
| <p>A main remote should try to avoid containing a lot of oversize | |
| blobs. For that purpose, it should offload as needed to a LOP and it | |
| should have ways to prevent oversize blobs to be fetched, and also | |
| perhaps pushed, into it.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_rationale_5">Rationale</h4> | |
| <div class="paragraph"> | |
| <p>A main remote containing many oversize blobs would defeat the purpose | |
| of LOPs.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_implementation_4">Implementation</h4> | |
| <div class="paragraph"> | |
| <p>The way to offload to a LOP discussed in 4) above can be used to | |
| regularly offload oversize blobs. About preventing oversize blobs from | |
| being fetched into the repo see 6) below. About preventing oversize | |
| blob pushes, a pre-receive hook could be used.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Also there are different scenarios in which large blobs could get | |
| fetched into the main remote, for example:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>A client that doesn’t implement the "promisor-remote" protocol | |
| (described in 6) below) clones from the main remote.</p> | |
| </li> | |
| <li> | |
| <p>The main remote gets a request for information about a large blob | |
| and is not able to get that information without fetching the blob | |
| from the LOP.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>It might not be possible to completely prevent all these scenarios | |
| from happening. So the goal here should be to implement features that | |
| make the fetching of large blobs less likely. For example adding a | |
| <code>remote-object-info</code> command in the <code>git</code> <code>cat-file</code> <code>--batch</code> protocol | |
| and its variants might make it possible for a main repo to respond to | |
| some requests about large blobs without fetching them.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_6_a_protocol_negotiation_should_happen_when_a_client_clones">6) A protocol negotiation should happen when a client clones</h3> | |
| <div class="paragraph"> | |
| <p>When a client clones from a main repo, there should be a protocol | |
| negotiation so that the server can advertise one or more LOPs and so | |
| that the client and the server can discuss if the client could | |
| directly use a LOP the server is advertising. If the client and the | |
| server can agree on that, then the client would be able to get the | |
| large blobs directly from the LOP and the server would not need to | |
| fetch those blobs from the LOP to be able to serve the client.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_note_3">Note</h4> | |
| <div class="paragraph"> | |
| <p>For fetches instead of clones, a protocol negotiation might not always | |
| happen, see the "What about fetches?" FAQ entry below for details.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_rationale_6">Rationale</h4> | |
| <div class="paragraph"> | |
| <p>Security, configurability and efficiency of setting things up.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_implementation_5">Implementation</h4> | |
| <div class="paragraph"> | |
| <p>A "promisor-remote" protocol v2 capability looks like a good way to | |
| implement this. The way the client and server use this capability | |
| could be controlled by configuration variables.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Information that the server could send to the client through that | |
| protocol could be things like: LOP name, LOP URL, filter-spec (for | |
| example <code>blob:limit=</code><em><size></em>) or just size limit that should be used as | |
| a filter when cloning, token to be used with the LOP, etc.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_7_a_client_can_offload_to_a_lop">7) A client can offload to a LOP</h3> | |
| <div class="paragraph"> | |
| <p>When a client is using a LOP that is also a LOP of its main remote, | |
| the client should be able to offload some large blobs it has fetched, | |
| but might not need anymore, to the LOP.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_note_4">Note</h4> | |
| <div class="paragraph"> | |
| <p>It might depend on the context if it should be OK or not for clients | |
| to offload large blobs they have created, instead of fetched, directly | |
| to the LOP without the main remote checking them in some ways | |
| (possibly using hooks or other tools).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This should be discussed and refined when we get closer to | |
| implementing this feature.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_rationale_7">Rationale</h4> | |
| <div class="paragraph"> | |
| <p>On the client, the easiest way to deal with unneeded large blobs is to | |
| offload them.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_implementation_6">Implementation</h4> | |
| <div class="paragraph"> | |
| <p>This is very similar to what 4) above is about, except on the client | |
| side instead of the server side. So a good solution to 4) could likely | |
| be adapted to work on the client side too.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>There might be some security issues here, as there is no negotiation, | |
| but they might be mitigated if the client can reuse a token it got | |
| when cloning (see 6) above). Also if the large blobs were fetched from | |
| a LOP, it is likely, and can easily be confirmed, that the LOP still | |
| has them, so that they can just be removed from the client.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_iii_benefits_of_using_lops">III Benefits of using LOPs</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>Many benefits are related to the issues discussed in "I) Issues with | |
| the current situation" above:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>No need to rewrite history when deciding which blobs are worth | |
| handling separately than other objects, or when moving or removing | |
| the threshold.</p> | |
| </li> | |
| <li> | |
| <p>If the protocol between client and server is developed and secured | |
| enough, then many details might be setup on the server side only and | |
| all the clients could then easily get all the configuration | |
| information and use it to set themselves up mostly automatically.</p> | |
| </li> | |
| <li> | |
| <p>Storage costs benefits on the server side.</p> | |
| </li> | |
| <li> | |
| <p>Reduced memory and CPU needs on main remotes on the server side.</p> | |
| </li> | |
| <li> | |
| <p>Reduced storage needs on the client side.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_iv_faq">IV FAQ</h2> | |
| <div class="sectionbody"> | |
| <div class="sect2"> | |
| <h3 id="_what_about_using_multiple_lops_on_the_server_and_client_side">What about using multiple LOPs on the server and client side?</h3> | |
| <div class="paragraph"> | |
| <p>That could perhaps be useful in some cases, but for now it’s more | |
| likely that in most cases a single LOP will be advertised by the | |
| server and should be used by the client.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>A case where it could be useful for a server to advertise multiple | |
| LOPs is if a LOP is better for some users while a different LOP is | |
| better for other users. For example some clients might have a better | |
| connection to a LOP than others.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In those cases it’s the responsibility of the server to have some | |
| documentation to help clients. It could say for example something like | |
| "Users in this part of the world might want to pick only LOP A as it | |
| is likely to be better connected to them, while users in other parts | |
| of the world should pick only LOP B for the same reason."</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_when_should_we_trust_or_not_trust_the_lops_advertised_by_the_server">When should we trust or not trust the LOPs advertised by the server?</h3> | |
| <div class="paragraph"> | |
| <p>In some contexts, like in corporate setup where the server and all the | |
| clients are parts of an internal network in a company where admins | |
| have all the rights on every system, it’s OK, and perhaps even a good | |
| thing, if the clients fully trust the server, as it can help ensure | |
| that all the clients are on the same page.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>There are also contexts in which clients trust a code hosting platform | |
| serving them some repos, but might not fully trust other users | |
| managing or contributing to some of these repos. For example, the code | |
| hosting platform could have hooks in place to check that any object it | |
| receives doesn’t contain malware or otherwise bad content. In this | |
| case it might be OK for the client to use a main remote and its LOP if | |
| they are both hosted by the code hosting platform, but not if the LOP | |
| is hosted elsewhere (where the content is not checked).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In other contexts, a client should just not trust a server.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>So there should be different ways to configure how the client should | |
| behave when a server advertises a LOP to it at clone time.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>As the basic elements that a server can advertise about a LOP are a | |
| LOP name and a LOP URL, the client should base its decision about | |
| accepting a LOP on these elements.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>One simple way to be very strict in the LOP it accepts is for example | |
| for the client to check that the LOP is already configured on the | |
| client with the same name and URL as what the server advertises.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In general default and "safe" settings should require that the LOP are | |
| configured on the client separately from the "promisor-remote" | |
| protocol and that the client accepts a LOP only when information about | |
| it from the protocol matches what has been already configured | |
| separately.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_what_about_lop_names">What about LOP names?</h3> | |
| <div class="paragraph"> | |
| <p>In some contexts, for example if the clients sometimes fetch from each | |
| other, it can be a good idea for all the clients to use the same names | |
| for all the remotes they use, including LOPs.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In other contexts, each client might want to be able to give the name | |
| it wants to each remote, including each LOP, it interacts with.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>So there should be different ways to configure how the client accepts | |
| or not the LOP name the server advertises.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If a default or "safe" setting is used, then as such a setting should | |
| require that the LOP be configured separately, then the name would be | |
| configured separately and there is no risk that the server could | |
| dictate a name to a client.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_could_the_main_remote_be_bogged_down_by_old_or_paranoid_clients">Could the main remote be bogged down by old or paranoid clients?</h3> | |
| <div class="paragraph"> | |
| <p>Yes, it could happen if there are too many clients that are either | |
| unwilling to trust the main remote or that just don’t implement the | |
| "promisor-remote" protocol because they are too old or not fully | |
| compatible with the <em>git</em> client.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>When serving such a client, the main remote has no other choice than | |
| to first fetch from its LOP, to then be able to provide to the client | |
| everything it requested. So the main remote, even if it has cleanup | |
| mechanisms (see section II.4 above), would be burdened at least | |
| temporarily with the large blobs it had to fetch from its LOP.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Not behaving like this would be breaking backward compatibility, and | |
| could be seen as segregating clients. For example, it might be | |
| possible to implement a special mode that allows the server to just | |
| reject clients that don’t implement the "promisor-remote" protocol or | |
| aren’t willing to trust the main remote. This mode might be useful in | |
| a special context like a corporate environment. There is no plan to | |
| implement such a mode though, and this should be discussed separately | |
| later anyway.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>A better way to proceed is probably for the main remote to show a | |
| message telling clients that don’t implement the protocol or are | |
| unwilling to accept the advertised LOP(s) that they would get faster | |
| clone and fetches by upgrading client software or properly setting | |
| them up to accept LOP(s).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Waiting for clients to upgrade, monitoring these upgrades and limiting | |
| the use of LOPs to repos that are not very frequently accessed might | |
| be other good ways to make sure that some benefits are still reaped | |
| from LOPs. Over time, as more and more clients upgrade and benefit | |
| from LOPs, using them in more and more frequently accessed repos will | |
| become worth it.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Corporate environments, where it might be easier to make sure that all | |
| the clients are up-to-date and properly configured, could hopefully | |
| benefit more and earlier from using LOPs.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_what_about_fetches">What about fetches?</h3> | |
| <div class="paragraph"> | |
| <p>There are different kinds of fetches. A regular fetch happens when | |
| some refs have been updated on the server and the client wants the ref | |
| updates and possibly the new objects added with them. A "backfill" or | |
| "lazy" fetch, on the contrary, happens when the client needs to use | |
| some objects it already knows about but doesn’t have because they are | |
| on a promisor remote.</p> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_regular_fetch">Regular fetch</h4> | |
| <div class="paragraph"> | |
| <p>In a regular fetch, the client will contact the main remote and a | |
| protocol negotiation will happen between them. It’s a good thing that | |
| a protocol negotiation happens every time, as the configuration on the | |
| client or the main remote could have changed since the previous | |
| protocol negotiation. In this case, the new protocol negotiation | |
| should ensure that the new fetch will happen in a way that satisfies | |
| the new configuration of both the client and the server.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In most cases though, the configurations on the client and the main | |
| remote will not have changed between 2 fetches or between the initial | |
| clone and a subsequent fetch. This means that the result of a new | |
| protocol negotiation will be the same as the previous result, so the | |
| new fetch will happen in the same way as the previous clone or fetch, | |
| using, or not using, the same LOP(s) as last time.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_backfill_or_lazy_fetch">"Backfill" or "lazy" fetch</h4> | |
| <div class="paragraph"> | |
| <p>When there is a backfill fetch, the client doesn’t necessarily contact | |
| the main remote first. It will try to fetch from its promisor remotes | |
| in the order they appear in the config file, except that a remote | |
| configured using the <code>extensions.partialClone</code> config variable will be | |
| tried last. See | |
| <a href="partial-clone.html#using-many-promisor-remotes">the partial clone documentation</a>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This is not new with this effort. In fact this is how multiple remotes | |
| have already been working for around 5 years.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>When using LOPs, having the main remote configured using | |
| <code>extensions.partialClone</code>, so it’s tried last, makes sense, as missing | |
| objects should only be large blobs that are on LOPs.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This means that a protocol negotiation will likely not happen as the | |
| missing objects will be fetched from the LOPs, and then there will be | |
| nothing left to fetch from the main remote.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>To secure that, it could be a good idea for LOPs to require a token | |
| from the client when it fetches from them. The client could get the | |
| token when performing a protocol negotiation with the main remote (see | |
| section II.6 above).</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_v_future_improvements">V Future improvements</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>It is expected that at the beginning using LOPs will be mostly worth | |
| it either in a corporate context where the Git version that clients | |
| use can easily be controlled, or on repos that are infrequently | |
| accessed. (See the "Could the main remote be bogged down by old or | |
| paranoid clients?" section in the FAQ above.)</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Over time, as more and more clients upgrade to a version that | |
| implements the "promisor-remote" protocol v2 capability described | |
| above in section II.6), it will be worth it to use LOPs more widely.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>A lot of improvements may also help using LOPs more widely. Some of | |
| these improvements are part of the scope of this document like the | |
| following:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>Implementing a "remote-object-info" command in the | |
| <code>git</code> <code>cat-file</code> <code>--batch</code> protocol and its variants to allow main | |
| remotes to respond to requests about large blobs without fetching | |
| them. (Eric Ju has started working on this based on previous work | |
| by Calvin Wan.)</p> | |
| </li> | |
| <li> | |
| <p>Creating better cleanup and offload mechanisms for main remotes | |
| and clients to prevent accumulation of large blobs.</p> | |
| </li> | |
| <li> | |
| <p>Developing more sophisticated protocol negotiation capabilities | |
| between clients and servers for handling LOPs, for example adding | |
| a filter-spec (e.g., blob:limit=<size>) or size limit for | |
| filtering when cloning, or adding a token for LOP authentication.</p> | |
| </li> | |
| <li> | |
| <p>Improving security measures for LOP access, particularly around | |
| token handling and authentication.</p> | |
| </li> | |
| <li> | |
| <p>Developing standardized ways to configure and manage multiple LOPs | |
| across different environments. Especially in the case where | |
| different LOPs serve the same content to clients in different | |
| geographical locations, there is a need for replication or | |
| synchronization between LOPs.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Some improvements, including some that have been mentioned in the "0) | |
| Non Goals" section of this document, are out of the scope of this | |
| document:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>Implementing a new object representation for large blobs on the | |
| client side.</p> | |
| </li> | |
| <li> | |
| <p>Developing pluggable ODBs or other object database backends that | |
| could chunk large blobs, dedup the chunks and store them | |
| efficiently.</p> | |
| </li> | |
| <li> | |
| <p>Optimizing data transfer between LOPs and clients/servers, | |
| particularly for incompressible and non-deltifying content.</p> | |
| </li> | |
| <li> | |
| <p>Creating improved client side tools for managing large objects | |
| more effectively, for example tools for migrating from Git LFS or | |
| git-annex, or tools to find which objects could be offloaded and | |
| how much disk space could be reclaimed by offloading them.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Some improvements could be seen as part of the scope of this document, | |
| but might already have their own separate projects from the Git | |
| project, like:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>Improving existing remote helpers to access object storage or | |
| developing new ones.</p> | |
| </li> | |
| <li> | |
| <p>Improving existing object storage solutions or developing new | |
| ones.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Even though all the above improvements may help, this document and the | |
| LOP effort should try to focus, at least first, on a relatively small | |
| number of improvements mostly those that are in its current scope.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>For example introducing pluggable ODBs and a new object database | |
| backend is likely a multi-year effort on its own that can happen | |
| separately in parallel. It has different technical requirements, | |
| touches other part of the Git code base and should have its own design | |
| document(s).</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated 2025-10-24 14:37:25 -0700 | |
| </div> | |
| </div> | |
| </body> | |
| </html> |