| <!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.23"/> |
| <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>code{display:block} |
| 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 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> |
