| <!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>Submitting Patches</title> | |
| <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"/> | |
| <style> | |
| /*! Asciidoctor default stylesheet | MIT License | https://asciidoctor.org */ | |
| /* Uncomment the following line when using as a custom stylesheet */ | |
| /* @import "https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700"; */ | |
| html{font-family:sans-serif;-webkit-text-size-adjust:100%} | |
| a{background:none} | |
| a:focus{outline:thin dotted} | |
| a:active,a:hover{outline:0} | |
| h1{font-size:2em;margin:.67em 0} | |
| b,strong{font-weight:bold} | |
| abbr{font-size:.9em} | |
| abbr[title]{cursor:help;border-bottom:1px dotted #dddddf;text-decoration:none} | |
| dfn{font-style:italic} | |
| hr{height:0} | |
| mark{background:#ff0;color:#000} | |
| code,kbd,pre,samp{font-family:monospace;font-size:1em} | |
| pre{white-space:pre-wrap} | |
| q{quotes:"\201C" "\201D" "\2018" "\2019"} | |
| small{font-size:80%} | |
| sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline} | |
| sup{top:-.5em} | |
| sub{bottom:-.25em} | |
| img{border:0} | |
| svg:not(:root){overflow:hidden} | |
| figure{margin:0} | |
| audio,video{display:inline-block} | |
| audio:not([controls]){display:none;height:0} | |
| fieldset{border:1px solid silver;margin:0 2px;padding:.35em .625em .75em} | |
| legend{border:0;padding:0} | |
| button,input,select,textarea{font-family:inherit;font-size:100%;margin:0} | |
| button,input{line-height:normal} | |
| button,select{text-transform:none} | |
| button,html input[type=button],input[type=reset],input[type=submit]{-webkit-appearance:button;cursor:pointer} | |
| button[disabled],html input[disabled]{cursor:default} | |
| input[type=checkbox],input[type=radio]{padding:0} | |
| button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0} | |
| textarea{overflow:auto;vertical-align:top} | |
| table{border-collapse:collapse;border-spacing:0} | |
| *,::before,::after{box-sizing:border-box} | |
| html,body{font-size:100%} | |
| body{background:#fff;color:rgba(0,0,0,.8);padding:0;margin:0;font-family:"Noto Serif","DejaVu Serif",serif;line-height:1;position:relative;cursor:auto;-moz-tab-size:4;-o-tab-size:4;tab-size:4;word-wrap:anywhere;-moz-osx-font-smoothing:grayscale;-webkit-font-smoothing:antialiased} | |
| a:hover{cursor:pointer} | |
| img,object,embed{max-width:100%;height:auto} | |
| object,embed{height:100%} | |
| img{-ms-interpolation-mode:bicubic} | |
| .left{float:left!important} | |
| .right{float:right!important} | |
| .text-left{text-align:left!important} | |
| .text-right{text-align:right!important} | |
| .text-center{text-align:center!important} | |
| .text-justify{text-align:justify!important} | |
| .hide{display:none} | |
| img,object,svg{display:inline-block;vertical-align:middle} | |
| textarea{height:auto;min-height:50px} | |
| select{width:100%} | |
| .subheader,.admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{line-height:1.45;color:#7a2518;font-weight:400;margin-top:0;margin-bottom:.25em} | |
| div,dl,dt,dd,ul,ol,li,h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0} | |
| a{color:#2156a5;text-decoration:underline;line-height:inherit} | |
| a:hover,a:focus{color:#1d4b8f} | |
| a img{border:0} | |
| p{line-height:1.6;margin-bottom:1.25em;text-rendering:optimizeLegibility} | |
| p aside{font-size:.875em;line-height:1.35;font-style:italic} | |
| h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{font-family:"Open Sans","DejaVu Sans",sans-serif;font-weight:300;font-style:normal;color:#ba3925;text-rendering:optimizeLegibility;margin-top:1em;margin-bottom:.5em;line-height:1.0125em} | |
| h1 small,h2 small,h3 small,#toctitle small,.sidebarblock>.content>.title small,h4 small,h5 small,h6 small{font-size:60%;color:#e99b8f;line-height:0} | |
| h1{font-size:2.125em} | |
| h2{font-size:1.6875em} | |
| h3,#toctitle,.sidebarblock>.content>.title{font-size:1.375em} | |
| h4,h5{font-size:1.125em} | |
| h6{font-size:1em} | |
| hr{border:solid #dddddf;border-width:1px 0 0;clear:both;margin:1.25em 0 1.1875em} | |
| em,i{font-style:italic;line-height:inherit} | |
| strong,b{font-weight:bold;line-height:inherit} | |
| small{font-size:60%;line-height:inherit} | |
| code{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;font-weight:400;color:rgba(0,0,0,.9)} | |
| ul,ol,dl{line-height:1.6;margin-bottom:1.25em;list-style-position:outside;font-family:inherit} | |
| ul,ol{margin-left:1.5em} | |
| ul li ul,ul li ol{margin-left:1.25em;margin-bottom:0} | |
| ul.circle{list-style-type:circle} | |
| ul.disc{list-style-type:disc} | |
| ul.square{list-style-type:square} | |
| ul.circle ul:not([class]),ul.disc ul:not([class]),ul.square ul:not([class]){list-style:inherit} | |
| ol li ul,ol li ol{margin-left:1.25em;margin-bottom:0} | |
| dl dt{margin-bottom:.3125em;font-weight:bold} | |
| dl dd{margin-bottom:1.25em} | |
| blockquote{margin:0 0 1.25em;padding:.5625em 1.25em 0 1.1875em;border-left:1px solid #ddd} | |
| blockquote,blockquote p{line-height:1.6;color:rgba(0,0,0,.85)} | |
| @media screen and (min-width:768px){h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2} | |
| h1{font-size:2.75em} | |
| h2{font-size:2.3125em} | |
| h3,#toctitle,.sidebarblock>.content>.title{font-size:1.6875em} | |
| h4{font-size:1.4375em}} | |
| table{background:#fff;margin-bottom:1.25em;border:1px solid #dedede;word-wrap:normal} | |
| table thead,table tfoot{background:#f7f8f7} | |
| table thead tr th,table thead tr td,table tfoot tr th,table tfoot tr td{padding:.5em .625em .625em;font-size:inherit;color:rgba(0,0,0,.8);text-align:left} | |
| table tr th,table tr td{padding:.5625em .625em;font-size:inherit;color:rgba(0,0,0,.8)} | |
| table tr.even,table tr.alt{background:#f8f8f7} | |
| table thead tr th,table tfoot tr th,table tbody tr td,table tr td,table tfoot tr td{line-height:1.6} | |
| h1,h2,h3,#toctitle,.sidebarblock>.content>.title,h4,h5,h6{line-height:1.2;word-spacing:-.05em} | |
| h1 strong,h2 strong,h3 strong,#toctitle strong,.sidebarblock>.content>.title strong,h4 strong,h5 strong,h6 strong{font-weight:400} | |
| .center{margin-left:auto;margin-right:auto} | |
| .stretch{width:100%} | |
| .clearfix::before,.clearfix::after,.float-group::before,.float-group::after{content:" ";display:table} | |
| .clearfix::after,.float-group::after{clear:both} | |
| :not(pre).nobreak{word-wrap:normal} | |
| :not(pre).nowrap{white-space:nowrap} | |
| :not(pre).pre-wrap{white-space:pre-wrap} | |
| :not(pre):not([class^=L])>code{font-size:.9375em;font-style:normal!important;letter-spacing:0;padding:.1em .5ex;word-spacing:-.15em;background:#f7f7f8;border-radius:4px;line-height:1.45;text-rendering:optimizeSpeed} | |
| pre{color:rgba(0,0,0,.9);font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;line-height:1.45;text-rendering:optimizeSpeed} | |
| pre code,pre pre{color:inherit;font-size:inherit;line-height:inherit} | |
| pre.nowrap,pre.nowrap pre{white-space:pre;word-wrap:normal} | |
| em em{font-style:normal} | |
| strong strong{font-weight:400} | |
| .keyseq{color:rgba(51,51,51,.8)} | |
| kbd{font-family:"Droid Sans Mono","DejaVu Sans Mono",monospace;display:inline-block;color:rgba(0,0,0,.8);font-size:.65em;line-height:1.45;background:#f7f7f7;border:1px solid #ccc;border-radius:3px;box-shadow:0 1px 0 rgba(0,0,0,.2),inset 0 0 0 .1em #fff;margin:0 .15em;padding:.2em .5em;vertical-align:middle;position:relative;top:-.1em;white-space:nowrap} | |
| .keyseq kbd:first-child{margin-left:0} | |
| .keyseq kbd:last-child{margin-right:0} | |
| .menuseq,.menuref{color:#000} | |
| .menuseq b:not(.caret),.menuref{font-weight:inherit} | |
| .menuseq{word-spacing:-.02em} | |
| .menuseq b.caret{font-size:1.25em;line-height:.8} | |
| .menuseq i.caret{font-weight:bold;text-align:center;width:.45em} | |
| b.button::before,b.button::after{position:relative;top:-1px;font-weight:400} | |
| b.button::before{content:"[";padding:0 3px 0 2px} | |
| b.button::after{content:"]";padding:0 2px 0 3px} | |
| p a>code:hover{color:rgba(0,0,0,.9)} | |
| #header,#content,#footnotes,#footer{width:100%;margin:0 auto;max-width:62.5em;*zoom:1;position:relative;padding-left:.9375em;padding-right:.9375em} | |
| #header::before,#header::after,#content::before,#content::after,#footnotes::before,#footnotes::after,#footer::before,#footer::after{content:" ";display:table} | |
| #header::after,#content::after,#footnotes::after,#footer::after{clear:both} | |
| #content{margin-top:1.25em} | |
| #content::before{content:none} | |
| #header>h1:first-child{color:rgba(0,0,0,.85);margin-top:2.25rem;margin-bottom:0} | |
| #header>h1:first-child+#toc{margin-top:8px;border-top:1px solid #dddddf} | |
| #header>h1:only-child{border-bottom:1px solid #dddddf;padding-bottom:8px} | |
| #header .details{border-bottom:1px solid #dddddf;line-height:1.45;padding-top:.25em;padding-bottom:.25em;padding-left:.25em;color:rgba(0,0,0,.6);display:flex;flex-flow:row wrap} | |
| #header .details span:first-child{margin-left:-.125em} | |
| #header .details span.email a{color:rgba(0,0,0,.85)} | |
| #header .details br{display:none} | |
| #header .details br+span::before{content:"\00a0\2013\00a0"} | |
| #header .details br+span.author::before{content:"\00a0\22c5\00a0";color:rgba(0,0,0,.85)} | |
| #header .details br+span#revremark::before{content:"\00a0|\00a0"} | |
| #header #revnumber{text-transform:capitalize} | |
| #header #revnumber::after{content:"\00a0"} | |
| #content>h1:first-child:not([class]){color:rgba(0,0,0,.85);border-bottom:1px solid #dddddf;padding-bottom:8px;margin-top:0;padding-top:1rem;margin-bottom:1.25rem} | |
| #toc{border-bottom:1px solid #e7e7e9;padding-bottom:.5em} | |
| #toc>ul{margin-left:.125em} | |
| #toc ul.sectlevel0>li>a{font-style:italic} | |
| #toc ul.sectlevel0 ul.sectlevel1{margin:.5em 0} | |
| #toc ul{font-family:"Open Sans","DejaVu Sans",sans-serif;list-style-type:none} | |
| #toc li{line-height:1.3334;margin-top:.3334em} | |
| #toc a{text-decoration:none} | |
| #toc a:active{text-decoration:underline} | |
| #toctitle{color:#7a2518;font-size:1.2em} | |
| @media screen and (min-width:768px){#toctitle{font-size:1.375em} | |
| body.toc2{padding-left:15em;padding-right:0} | |
| body.toc2 #header>h1:nth-last-child(2){border-bottom:1px solid #dddddf;padding-bottom:8px} | |
| #toc.toc2{margin-top:0!important;background:#f8f8f7;position:fixed;width:15em;left:0;top:0;border-right:1px solid #e7e7e9;border-top-width:0!important;border-bottom-width:0!important;z-index:1000;padding:1.25em 1em;height:100%;overflow:auto} | |
| #toc.toc2 #toctitle{margin-top:0;margin-bottom:.8rem;font-size:1.2em} | |
| #toc.toc2>ul{font-size:.9em;margin-bottom:0} | |
| #toc.toc2 ul ul{margin-left:0;padding-left:1em} | |
| #toc.toc2 ul.sectlevel0 ul.sectlevel1{padding-left:0;margin-top:.5em;margin-bottom:.5em} | |
| body.toc2.toc-right{padding-left:0;padding-right:15em} | |
| body.toc2.toc-right #toc.toc2{border-right-width:0;border-left:1px solid #e7e7e9;left:auto;right:0}} | |
| @media screen and (min-width:1280px){body.toc2{padding-left:20em;padding-right:0} | |
| #toc.toc2{width:20em} | |
| #toc.toc2 #toctitle{font-size:1.375em} | |
| #toc.toc2>ul{font-size:.95em} | |
| #toc.toc2 ul ul{padding-left:1.25em} | |
| body.toc2.toc-right{padding-left:0;padding-right:20em}} | |
| #content #toc{border:1px solid #e0e0dc;margin-bottom:1.25em;padding:1.25em;background:#f8f8f7;border-radius:4px} | |
| #content #toc>:first-child{margin-top:0} | |
| #content #toc>:last-child{margin-bottom:0} | |
| #footer{max-width:none;background:rgba(0,0,0,.8);padding:1.25em} | |
| #footer-text{color:hsla(0,0%,100%,.8);line-height:1.44} | |
| #content{margin-bottom:.625em} | |
| .sect1{padding-bottom:.625em} | |
| @media screen and (min-width:768px){#content{margin-bottom:1.25em} | |
| .sect1{padding-bottom:1.25em}} | |
| .sect1:last-child{padding-bottom:0} | |
| .sect1+.sect1{border-top:1px solid #e7e7e9} | |
| #content h1>a.anchor,h2>a.anchor,h3>a.anchor,#toctitle>a.anchor,.sidebarblock>.content>.title>a.anchor,h4>a.anchor,h5>a.anchor,h6>a.anchor{position:absolute;z-index:1001;width:1.5ex;margin-left:-1.5ex;display:block;text-decoration:none!important;visibility:hidden;text-align:center;font-weight:400} | |
| #content h1>a.anchor::before,h2>a.anchor::before,h3>a.anchor::before,#toctitle>a.anchor::before,.sidebarblock>.content>.title>a.anchor::before,h4>a.anchor::before,h5>a.anchor::before,h6>a.anchor::before{content:"\00A7";font-size:.85em;display:block;padding-top:.1em} | |
| #content h1:hover>a.anchor,#content h1>a.anchor:hover,h2:hover>a.anchor,h2>a.anchor:hover,h3:hover>a.anchor,#toctitle:hover>a.anchor,.sidebarblock>.content>.title:hover>a.anchor,h3>a.anchor:hover,#toctitle>a.anchor:hover,.sidebarblock>.content>.title>a.anchor:hover,h4:hover>a.anchor,h4>a.anchor:hover,h5:hover>a.anchor,h5>a.anchor:hover,h6:hover>a.anchor,h6>a.anchor:hover{visibility:visible} | |
| #content h1>a.link,h2>a.link,h3>a.link,#toctitle>a.link,.sidebarblock>.content>.title>a.link,h4>a.link,h5>a.link,h6>a.link{color:#ba3925;text-decoration:none} | |
| #content h1>a.link:hover,h2>a.link:hover,h3>a.link:hover,#toctitle>a.link:hover,.sidebarblock>.content>.title>a.link:hover,h4>a.link:hover,h5>a.link:hover,h6>a.link:hover{color:#a53221} | |
| details,.audioblock,.imageblock,.literalblock,.listingblock,.stemblock,.videoblock{margin-bottom:1.25em} | |
| details{margin-left:1.25rem} | |
| details>summary{cursor:pointer;display:block;position:relative;line-height:1.6;margin-bottom:.625rem;outline:none;-webkit-tap-highlight-color:transparent} | |
| details>summary::-webkit-details-marker{display:none} | |
| details>summary::before{content:"";border:solid transparent;border-left:solid;border-width:.3em 0 .3em .5em;position:absolute;top:.5em;left:-1.25rem;transform:translateX(15%)} | |
| details[open]>summary::before{border:solid transparent;border-top:solid;border-width:.5em .3em 0;transform:translateY(15%)} | |
| details>summary::after{content:"";width:1.25rem;height:1em;position:absolute;top:.3em;left:-1.25rem} | |
| .admonitionblock td.content>.title,.audioblock>.title,.exampleblock>.title,.imageblock>.title,.listingblock>.title,.literalblock>.title,.stemblock>.title,.openblock>.title,.paragraph>.title,.quoteblock>.title,table.tableblock>.title,.verseblock>.title,.videoblock>.title,.dlist>.title,.olist>.title,.ulist>.title,.qlist>.title,.hdlist>.title{text-rendering:optimizeLegibility;text-align:left;font-family:"Noto Serif","DejaVu Serif",serif;font-size:1rem;font-style:italic} | |
| table.tableblock.fit-content>caption.title{white-space:nowrap;width:0} | |
| .paragraph.lead>p,#preamble>.sectionbody>[class=paragraph]:first-of-type p{font-size:1.21875em;line-height:1.6;color:rgba(0,0,0,.85)} | |
| .admonitionblock>table{border-collapse:separate;border:0;background:none;width:100%} | |
| .admonitionblock>table td.icon{text-align:center;width:80px} | |
| .admonitionblock>table td.icon img{max-width:none} | |
| .admonitionblock>table td.icon .title{font-weight:bold;font-family:"Open Sans","DejaVu Sans",sans-serif;text-transform:uppercase} | |
| .admonitionblock>table td.content{padding-left:1.125em;padding-right:1.25em;border-left:1px solid #dddddf;color:rgba(0,0,0,.6);word-wrap:anywhere} | |
| .admonitionblock>table td.content>:last-child>:last-child{margin-bottom:0} | |
| .exampleblock>.content{border:1px solid #e6e6e6;margin-bottom:1.25em;padding:1.25em;background:#fff;border-radius:4px} | |
| .sidebarblock{border:1px solid #dbdbd6;margin-bottom:1.25em;padding:1.25em;background:#f3f3f2;border-radius:4px} | |
| .sidebarblock>.content>.title{color:#7a2518;margin-top:0;text-align:center} | |
| .exampleblock>.content>:first-child,.sidebarblock>.content>:first-child{margin-top:0} | |
| .exampleblock>.content>:last-child,.exampleblock>.content>:last-child>:last-child,.exampleblock>.content .olist>ol>li:last-child>:last-child,.exampleblock>.content .ulist>ul>li:last-child>:last-child,.exampleblock>.content .qlist>ol>li:last-child>:last-child,.sidebarblock>.content>:last-child,.sidebarblock>.content>:last-child>:last-child,.sidebarblock>.content .olist>ol>li:last-child>:last-child,.sidebarblock>.content .ulist>ul>li:last-child>:last-child,.sidebarblock>.content .qlist>ol>li:last-child>:last-child{margin-bottom:0} | |
| .literalblock pre,.listingblock>.content>pre{border-radius:4px;overflow-x:auto;padding:1em;font-size:.8125em} | |
| @media screen and (min-width:768px){.literalblock pre,.listingblock>.content>pre{font-size:.90625em}} | |
| @media screen and (min-width:1280px){.literalblock pre,.listingblock>.content>pre{font-size:1em}} | |
| .literalblock pre,.listingblock>.content>pre:not(.highlight),.listingblock>.content>pre[class=highlight],.listingblock>.content>pre[class^="highlight "]{background:#f7f7f8} | |
| .literalblock.output pre{color:#f7f7f8;background:rgba(0,0,0,.9)} | |
| .listingblock>.content{position:relative} | |
| .listingblock pre>code{display:block} | |
| .listingblock code[data-lang]::before{display:none;content:attr(data-lang);position:absolute;font-size:.75em;top:.425rem;right:.5rem;line-height:1;text-transform:uppercase;color:inherit;opacity:.5} | |
| .listingblock:hover code[data-lang]::before{display:block} | |
| .listingblock.terminal pre .command::before{content:attr(data-prompt);padding-right:.5em;color:inherit;opacity:.5} | |
| .listingblock.terminal pre .command:not([data-prompt])::before{content:"$"} | |
| .listingblock pre.highlightjs{padding:0} | |
| .listingblock pre.highlightjs>code{padding:1em;border-radius:4px} | |
| .listingblock pre.prettyprint{border-width:0} | |
| .prettyprint{background:#f7f7f8} | |
| pre.prettyprint .linenums{line-height:1.45;margin-left:2em} | |
| pre.prettyprint li{background:none;list-style-type:inherit;padding-left:0} | |
| pre.prettyprint li code[data-lang]::before{opacity:1} | |
| pre.prettyprint li:not(:first-child) code[data-lang]::before{display:none} | |
| table.linenotable{border-collapse:separate;border:0;margin-bottom:0;background:none} | |
| table.linenotable td[class]{color:inherit;vertical-align:top;padding:0;line-height:inherit;white-space:normal} | |
| table.linenotable td.code{padding-left:.75em} | |
| table.linenotable td.linenos,pre.pygments .linenos{border-right:1px solid;opacity:.35;padding-right:.5em;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none} | |
| pre.pygments span.linenos{display:inline-block;margin-right:.75em} | |
| .quoteblock{margin:0 1em 1.25em 1.5em;display:table} | |
| .quoteblock:not(.excerpt)>.title{margin-left:-1.5em;margin-bottom:.75em} | |
| .quoteblock blockquote,.quoteblock p{color:rgba(0,0,0,.85);font-size:1.15rem;line-height:1.75;word-spacing:.1em;letter-spacing:0;font-style:italic;text-align:justify} | |
| .quoteblock blockquote{margin:0;padding:0;border:0} | |
| .quoteblock blockquote::before{content:"\201c";float:left;font-size:2.75em;font-weight:bold;line-height:.6em;margin-left:-.6em;color:#7a2518;text-shadow:0 1px 2px rgba(0,0,0,.1)} | |
| .quoteblock blockquote>.paragraph:last-child p{margin-bottom:0} | |
| .quoteblock .attribution{margin-top:.75em;margin-right:.5ex;text-align:right} | |
| .verseblock{margin:0 1em 1.25em} | |
| .verseblock pre{font-family:"Open Sans","DejaVu Sans",sans-serif;font-size:1.15rem;color:rgba(0,0,0,.85);font-weight:300;text-rendering:optimizeLegibility} | |
| .verseblock pre strong{font-weight:400} | |
| .verseblock .attribution{margin-top:1.25rem;margin-left:.5ex} | |
| .quoteblock .attribution,.verseblock .attribution{font-size:.9375em;line-height:1.45;font-style:italic} | |
| .quoteblock .attribution br,.verseblock .attribution br{display:none} | |
| .quoteblock .attribution cite,.verseblock .attribution cite{display:block;letter-spacing:-.025em;color:rgba(0,0,0,.6)} | |
| .quoteblock.abstract blockquote::before,.quoteblock.excerpt blockquote::before,.quoteblock .quoteblock blockquote::before{display:none} | |
| .quoteblock.abstract blockquote,.quoteblock.abstract p,.quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{line-height:1.6;word-spacing:0} | |
| .quoteblock.abstract{margin:0 1em 1.25em;display:block} | |
| .quoteblock.abstract>.title{margin:0 0 .375em;font-size:1.15em;text-align:center} | |
| .quoteblock.excerpt>blockquote,.quoteblock .quoteblock{padding:0 0 .25em 1em;border-left:.25em solid #dddddf} | |
| .quoteblock.excerpt,.quoteblock .quoteblock{margin-left:0} | |
| .quoteblock.excerpt blockquote,.quoteblock.excerpt p,.quoteblock .quoteblock blockquote,.quoteblock .quoteblock p{color:inherit;font-size:1.0625rem} | |
| .quoteblock.excerpt .attribution,.quoteblock .quoteblock .attribution{color:inherit;font-size:.85rem;text-align:left;margin-right:0} | |
| p.tableblock:last-child{margin-bottom:0} | |
| td.tableblock>.content{margin-bottom:1.25em;word-wrap:anywhere} | |
| td.tableblock>.content>:last-child{margin-bottom:-1.25em} | |
| table.tableblock,th.tableblock,td.tableblock{border:0 solid #dedede} | |
| table.grid-all>*>tr>*{border-width:1px} | |
| table.grid-cols>*>tr>*{border-width:0 1px} | |
| table.grid-rows>*>tr>*{border-width:1px 0} | |
| table.frame-all{border-width:1px} | |
| table.frame-ends{border-width:1px 0} | |
| table.frame-sides{border-width:0 1px} | |
| table.frame-none>colgroup+*>:first-child>*,table.frame-sides>colgroup+*>:first-child>*{border-top-width:0} | |
| table.frame-none>:last-child>:last-child>*,table.frame-sides>:last-child>:last-child>*{border-bottom-width:0} | |
| table.frame-none>*>tr>:first-child,table.frame-ends>*>tr>:first-child{border-left-width:0} | |
| table.frame-none>*>tr>:last-child,table.frame-ends>*>tr>:last-child{border-right-width:0} | |
| table.stripes-all>*>tr,table.stripes-odd>*>tr:nth-of-type(odd),table.stripes-even>*>tr:nth-of-type(even),table.stripes-hover>*>tr:hover{background:#f8f8f7} | |
| th.halign-left,td.halign-left{text-align:left} | |
| th.halign-right,td.halign-right{text-align:right} | |
| th.halign-center,td.halign-center{text-align:center} | |
| th.valign-top,td.valign-top{vertical-align:top} | |
| th.valign-bottom,td.valign-bottom{vertical-align:bottom} | |
| th.valign-middle,td.valign-middle{vertical-align:middle} | |
| table thead th,table tfoot th{font-weight:bold} | |
| tbody tr th{background:#f7f8f7} | |
| tbody tr th,tbody tr th p,tfoot tr th,tfoot tr th p{color:rgba(0,0,0,.8);font-weight:bold} | |
| p.tableblock>code:only-child{background:none;padding:0} | |
| p.tableblock{font-size:1em} | |
| ol{margin-left:1.75em} | |
| ul li ol{margin-left:1.5em} | |
| dl dd{margin-left:1.125em} | |
| dl dd:last-child,dl dd:last-child>:last-child{margin-bottom:0} | |
| li p,ul dd,ol dd,.olist .olist,.ulist .ulist,.ulist .olist,.olist .ulist{margin-bottom:.625em} | |
| ul.checklist,ul.none,ol.none,ul.no-bullet,ol.no-bullet,ol.unnumbered,ul.unstyled,ol.unstyled{list-style-type:none} | |
| ul.no-bullet,ol.no-bullet,ol.unnumbered{margin-left:.625em} | |
| ul.unstyled,ol.unstyled{margin-left:0} | |
| li>p:empty:only-child::before{content:"";display:inline-block} | |
| ul.checklist>li>p:first-child{margin-left:-1em} | |
| ul.checklist>li>p:first-child>.fa-square-o:first-child,ul.checklist>li>p:first-child>.fa-check-square-o:first-child{width:1.25em;font-size:.8em;position:relative;bottom:.125em} | |
| ul.checklist>li>p:first-child>input[type=checkbox]:first-child{margin-right:.25em} | |
| ul.inline{display:flex;flex-flow:row wrap;list-style:none;margin:0 0 .625em -1.25em} | |
| ul.inline>li{margin-left:1.25em} | |
| .unstyled dl dt{font-weight:400;font-style:normal} | |
| ol.arabic{list-style-type:decimal} | |
| ol.decimal{list-style-type:decimal-leading-zero} | |
| ol.loweralpha{list-style-type:lower-alpha} | |
| ol.upperalpha{list-style-type:upper-alpha} | |
| ol.lowerroman{list-style-type:lower-roman} | |
| ol.upperroman{list-style-type:upper-roman} | |
| ol.lowergreek{list-style-type:lower-greek} | |
| .hdlist>table,.colist>table{border:0;background:none} | |
| .hdlist>table>tbody>tr,.colist>table>tbody>tr{background:none} | |
| td.hdlist1,td.hdlist2{vertical-align:top;padding:0 .625em} | |
| td.hdlist1{font-weight:bold;padding-bottom:1.25em} | |
| td.hdlist2{word-wrap:anywhere} | |
| .literalblock+.colist,.listingblock+.colist{margin-top:-.5em} | |
| .colist td:not([class]):first-child{padding:.4em .75em 0;line-height:1;vertical-align:top} | |
| .colist td:not([class]):first-child img{max-width:none} | |
| .colist td:not([class]):last-child{padding:.25em 0} | |
| .thumb,.th{line-height:0;display:inline-block;border:4px solid #fff;box-shadow:0 0 0 1px #ddd} | |
| .imageblock.left{margin:.25em .625em 1.25em 0} | |
| .imageblock.right{margin:.25em 0 1.25em .625em} | |
| .imageblock>.title{margin-bottom:0} | |
| .imageblock.thumb,.imageblock.th{border-width:6px} | |
| .imageblock.thumb>.title,.imageblock.th>.title{padding:0 .125em} | |
| .image.left,.image.right{margin-top:.25em;margin-bottom:.25em;display:inline-block;line-height:0} | |
| .image.left{margin-right:.625em} | |
| .image.right{margin-left:.625em} | |
| a.image{text-decoration:none;display:inline-block} | |
| a.image object{pointer-events:none} | |
| sup.footnote,sup.footnoteref{font-size:.875em;position:static;vertical-align:super} | |
| sup.footnote a,sup.footnoteref a{text-decoration:none} | |
| sup.footnote a:active,sup.footnoteref a:active,#footnotes .footnote a:first-of-type:active{text-decoration:underline} | |
| #footnotes{padding-top:.75em;padding-bottom:.75em;margin-bottom:.625em} | |
| #footnotes hr{width:20%;min-width:6.25em;margin:-.25em 0 .75em;border-width:1px 0 0} | |
| #footnotes .footnote{padding:0 .375em 0 .225em;line-height:1.3334;font-size:.875em;margin-left:1.2em;margin-bottom:.2em} | |
| #footnotes .footnote a:first-of-type{font-weight:bold;text-decoration:none;margin-left:-1.05em} | |
| #footnotes .footnote:last-of-type{margin-bottom:0} | |
| #content #footnotes{margin-top:-.625em;margin-bottom:0;padding:.75em 0} | |
| div.unbreakable{page-break-inside:avoid} | |
| .big{font-size:larger} | |
| .small{font-size:smaller} | |
| .underline{text-decoration:underline} | |
| .overline{text-decoration:overline} | |
| .line-through{text-decoration:line-through} | |
| .aqua{color:#00bfbf} | |
| .aqua-background{background:#00fafa} | |
| .black{color:#000} | |
| .black-background{background:#000} | |
| .blue{color:#0000bf} | |
| .blue-background{background:#0000fa} | |
| .fuchsia{color:#bf00bf} | |
| .fuchsia-background{background:#fa00fa} | |
| .gray{color:#606060} | |
| .gray-background{background:#7d7d7d} | |
| .green{color:#006000} | |
| .green-background{background:#007d00} | |
| .lime{color:#00bf00} | |
| .lime-background{background:#00fa00} | |
| .maroon{color:#600000} | |
| .maroon-background{background:#7d0000} | |
| .navy{color:#000060} | |
| .navy-background{background:#00007d} | |
| .olive{color:#606000} | |
| .olive-background{background:#7d7d00} | |
| .purple{color:#600060} | |
| .purple-background{background:#7d007d} | |
| .red{color:#bf0000} | |
| .red-background{background:#fa0000} | |
| .silver{color:#909090} | |
| .silver-background{background:#bcbcbc} | |
| .teal{color:#006060} | |
| .teal-background{background:#007d7d} | |
| .white{color:#bfbfbf} | |
| .white-background{background:#fafafa} | |
| .yellow{color:#bfbf00} | |
| .yellow-background{background:#fafa00} | |
| span.icon>.fa{cursor:default} | |
| a span.icon>.fa{cursor:inherit} | |
| .admonitionblock td.icon [class^="fa icon-"]{font-size:2.5em;text-shadow:1px 1px 2px rgba(0,0,0,.5);cursor:default} | |
| .admonitionblock td.icon .icon-note::before{content:"\f05a";color:#19407c} | |
| .admonitionblock td.icon .icon-tip::before{content:"\f0eb";text-shadow:1px 1px 2px rgba(155,155,0,.8);color:#111} | |
| .admonitionblock td.icon .icon-warning::before{content:"\f071";color:#bf6900} | |
| .admonitionblock td.icon .icon-caution::before{content:"\f06d";color:#bf3400} | |
| .admonitionblock td.icon .icon-important::before{content:"\f06a";color:#bf0000} | |
| .conum[data-value]{display:inline-block;color:#fff!important;background:rgba(0,0,0,.8);border-radius:50%;text-align:center;font-size:.75em;width:1.67em;height:1.67em;line-height:1.67em;font-family:"Open Sans","DejaVu Sans",sans-serif;font-style:normal;font-weight:bold} | |
| .conum[data-value] *{color:#fff!important} | |
| .conum[data-value]+b{display:none} | |
| .conum[data-value]::after{content:attr(data-value)} | |
| pre .conum[data-value]{position:relative;top:-.125em} | |
| b.conum *{color:inherit!important} | |
| .conum:not([data-value]):empty{display:none} | |
| dt,th.tableblock,td.content,div.footnote{text-rendering:optimizeLegibility} | |
| h1,h2,p,td.content,span.alt,summary{letter-spacing:-.01em} | |
| p strong,td.content strong,div.footnote strong{letter-spacing:-.005em} | |
| p,blockquote,dt,td.content,td.hdlist1,span.alt,summary{font-size:1.0625rem} | |
| p{margin-bottom:1.25rem} | |
| .sidebarblock p,.sidebarblock dt,.sidebarblock td.content,p.tableblock{font-size:1em} | |
| .exampleblock>.content{background:#fffef7;border-color:#e0e0dc;box-shadow:0 1px 4px #e0e0dc} | |
| .print-only{display:none!important} | |
| @page{margin:1.25cm .75cm} | |
| @media print{*{box-shadow:none!important;text-shadow:none!important} | |
| html{font-size:80%} | |
| a{color:inherit!important;text-decoration:underline!important} | |
| a.bare,a[href^="#"],a[href^="mailto:"]{text-decoration:none!important} | |
| a[href^="http:"]:not(.bare)::after,a[href^="https:"]:not(.bare)::after{content:"(" attr(href) ")";display:inline-block;font-size:.875em;padding-left:.25em} | |
| abbr[title]{border-bottom:1px dotted} | |
| abbr[title]::after{content:" (" attr(title) ")"} | |
| pre,blockquote,tr,img,object,svg{page-break-inside:avoid} | |
| thead{display:table-header-group} | |
| svg{max-width:100%} | |
| p,blockquote,dt,td.content{font-size:1em;orphans:3;widows:3} | |
| h2,h3,#toctitle,.sidebarblock>.content>.title{page-break-after:avoid} | |
| #header,#content,#footnotes,#footer{max-width:none} | |
| #toc,.sidebarblock,.exampleblock>.content{background:none!important} | |
| #toc{border-bottom:1px solid #dddddf!important;padding-bottom:0!important} | |
| body.book #header{text-align:center} | |
| body.book #header>h1:first-child{border:0!important;margin:2.5em 0 1em} | |
| body.book #header .details{border:0!important;display:block;padding:0!important} | |
| body.book #header .details span:first-child{margin-left:0!important} | |
| body.book #header .details br{display:block} | |
| body.book #header .details br+span::before{content:none!important} | |
| body.book #toc{border:0!important;text-align:left!important;padding:0!important;margin:0!important} | |
| body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-break-before:always} | |
| .listingblock code[data-lang]::before{display:block} | |
| #footer{padding:0 .9375em} | |
| .hide-on-print{display:none!important} | |
| .print-only{display:block!important} | |
| .hide-for-print{display:none!important} | |
| .show-for-print{display:inherit!important}} | |
| @media amzn-kf8,print{#header>h1:first-child{margin-top:1.25rem} | |
| .sect1{padding:0!important} | |
| .sect1+.sect1{border:0} | |
| #footer{background:none} | |
| #footer-text{color:rgba(0,0,0,.6);font-size:.9em}} | |
| @media amzn-kf8{#header,#content,#footnotes,#footer{padding:0}} | |
| </style> | |
| <style> | |
| pre>code { | |
| display: inline; | |
| } | |
| </style> | |
| </head> | |
| <body class="article"> | |
| <div id="header"> | |
| <h1>Submitting Patches</h1> | |
| </div> | |
| <div id="content"> | |
| <div class="sect1"> | |
| <h2 id="_guidelines">Guidelines</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>Here are some guidelines for contributing back to this | |
| project. There is also a <a href="MyFirstContribution.html">step-by-step tutorial</a> | |
| available which covers many of these same guidelines.</p> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="patch-flow">A typical life cycle of a patch series</h3> | |
| <div class="paragraph"> | |
| <p>To help us understand the reason behind various guidelines given later | |
| in the document, first let’s understand how the life cycle of a | |
| typical patch series for this project goes.</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>You come up with an itch. You code it up. You do not need any | |
| pre-authorization from the project to do so.</p> | |
| <div class="paragraph"> | |
| <p>Your patches will be reviewed by other contributors on the mailing | |
| list, and the reviews will be done to assess the merit of various | |
| things, like the general idea behind your patch (including "is it | |
| solving a problem worth solving in the first place?"), the reason | |
| behind the design of the solution, and the actual implementation. | |
| The guidelines given here are there to help your patches by making | |
| them easier to understand by the reviewers.</p> | |
| </div> | |
| </li> | |
| <li> | |
| <p>You send the patches to the list and cc people who may need to know | |
| about the change. Your goal is <strong>not</strong> necessarily to convince others | |
| that what you are building is good. Your goal is to get help in | |
| coming up with a solution for the "itch" that is better than what | |
| you can build alone.</p> | |
| <div class="paragraph"> | |
| <p>The people who may need to know are the ones who worked on the code | |
| you are touching. These people happen to be the ones who are | |
| most likely to be knowledgeable enough to help you, but | |
| they have no obligation to help you (i.e. you ask them for help, | |
| you don’t demand). <code>git</code> <code>log</code> <code>-p</code> -- <code><em>$area_you_are_modifying</em></code> would | |
| help you find out who they are.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>It is also a good idea to check whether your topic has been discussed | |
| previously on the mailing list, or whether similar work is already in | |
| progress. Prior discussions may contain useful context, design | |
| considerations, or earlier attempts at solving the same problem. Being | |
| aware of such discussions can help you avoid duplicating work and may | |
| allow you to coordinate with other contributors working in the same | |
| area.</p> | |
| </div> | |
| </li> | |
| <li> | |
| <p>You get comments and suggestions for improvements. You may even get | |
| them in an "on top of your change" patch form. You are expected to | |
| respond to them with "Reply-All" on the mailing list, instead of | |
| letting an updated patch series be your only response. Tell | |
| reviewers which suggestions you plan to use, which ones you disagree | |
| with, and when a comment leads you to consider a different approach. | |
| Use these replies and any follow-up discussion as input when | |
| preparing an updated set of patches.</p> | |
| <div class="paragraph"> | |
| <p>Be particularly mindful of critiques regarding the high-level design | |
| or viability of your proposal (e.g., questioning if the feature is | |
| worth implementing, or if the chosen approach is appropriate). Defend | |
| your design decisions on the list first and work with reviewers and | |
| other members to improve the design before revising the implementation. | |
| This will avoid wasting effort on an implementation before its design is | |
| solid.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Make sure that any new version explains and justifies those design | |
| decisions more clearly, in the cover letter and in the revised commit | |
| messages. Aim to make the reviewers say "it is now clear why we may | |
| want to do this with the updated version".</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Topics with unresolved fundamental design critiques will not be | |
| considered ready for merging.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>It is often beneficial to allow some time for reviewers to provide | |
| feedback before sending a new version, rather than sending an updated | |
| series immediately after receiving a review. This helps collect broader | |
| input, gives reviewers in different time zones a fair chance to comment, | |
| and avoids unnecessary churn from many rapid iterations. Waiting also | |
| encourages you to polish each version before sending it, so reviewers | |
| can focus on substantial issues rather than typos or other small | |
| mistakes.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>As a rough default, avoid sending more than one new version of the same | |
| series per day, while considering the size of the series and the depth | |
| of review.</p> | |
| </div> | |
| </li> | |
| <li> | |
| <p>These early update iterations are expected to be full replacements, | |
| not incremental updates on top of what you posted already. If you | |
| are correcting mistakes you made in the previous iteration that a | |
| reviewer noticed and pointed out in their review, you <em>fix</em> that | |
| mistake by rewriting your history (e.g., by using "git rebase -i") | |
| to pretend that you never made the mistake in the first place. In | |
| other words, this is a chance to pretend to be a perfect developer, | |
| and you are expected to take advantage of that. In the larger | |
| picture, nobody is interested in your earlier mistakes. Just | |
| present a logical progression made by a perfect developer who makes | |
| no mistakes while working on the topic.</p> | |
| </li> | |
| <li> | |
| <p>Polish, refine, and re-send your patches to the list and to the people | |
| who spent their time to improve your patch. Go back to step (2).</p> | |
| </li> | |
| <li> | |
| <p>While the above iterations improve your patches, the maintainer may | |
| pick the patches up from the list and queue them to the <code>seen</code> | |
| branch, in order to make it easier for people to play with it | |
| without having to pick up and apply the patches to their trees | |
| themselves. Being in <code>seen</code> has no other meaning. Specifically, it | |
| does not mean the patch was "accepted" in any way.</p> | |
| </li> | |
| <li> | |
| <p>When the discussion reaches a consensus that the latest iteration of | |
| the patches are in good enough shape, the maintainer includes the | |
| topic in the "What’s cooking" report that are sent out a few times a | |
| week to the mailing list, marked as "Will merge to <em>next</em>." This | |
| decision is primarily made by the maintainer with help from those | |
| who participated in the review discussion.</p> | |
| </li> | |
| <li> | |
| <p>After the patches are merged to the <em>next</em> branch, the discussion | |
| can still continue to further improve them by adding more patches on | |
| top, but by the time a topic gets merged to <em>next</em>, it is expected | |
| that everybody agrees that the scope and the basic direction of the | |
| topic are appropriate, so such an incremental updates are limited to | |
| small corrections and polishing. After a topic cooks for some time | |
| (like 7 calendar days) in <em>next</em> without needing further tweaks on | |
| top, it gets merged to the <em>master</em> branch and waits to become part | |
| of the next major release.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div class="paragraph"> | |
| <p>But sometimes things do not work as planned:</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>If a mailing list discussion convinces you that your changes aren’t | |
| ideal, please explicitly retract the topic to save the maintainer | |
| time and effort.</p> | |
| </li> | |
| <li> | |
| <p>If you must drop a topic due to shifting priorities, lack of time, | |
| or other commitments, notify the list as a courtesy so others can | |
| take over. Anyone can resurrect the topic later when they have the | |
| capacity to do so.</p> | |
| </li> | |
| <li> | |
| <p>Topics with unaddressed review comments that remain inactive for | |
| four weeks may be discarded by the maintainer.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div class="paragraph"> | |
| <p>In the following sections, many techniques and conventions are listed | |
| to help your patches get reviewed effectively in such a life cycle.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="choose-starting-point">Choose a starting point.</h3> | |
| <div class="paragraph"> | |
| <p>As a preliminary step, you must first choose a starting point for your | |
| work. Typically this means choosing a branch, although technically | |
| speaking it is actually a particular commit (typically the HEAD, or tip, | |
| of the branch).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>There are several important branches to be aware of. Namely, there are | |
| four integration branches as discussed in <a href="gitworkflows.html">gitworkflows(7)</a>:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>maint</p> | |
| </li> | |
| <li> | |
| <p>master</p> | |
| </li> | |
| <li> | |
| <p>next</p> | |
| </li> | |
| <li> | |
| <p>seen</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The branches lower on the list are typically descendants of the ones | |
| that come before it. For example, <code>maint</code> is an "older" branch than | |
| <code>master</code> because <code>master</code> usually has patches (commits) on top of | |
| <code>maint</code>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>There are also "topic" branches, which contain work from other | |
| contributors. Topic branches are created by the Git maintainer (in | |
| their fork) to organize the current set of incoming contributions on | |
| the mailing list, and are itemized in the regular "What’s cooking in | |
| git.git" announcements. To find the tip of a topic branch, run <code>git</code> <code>log</code> | |
| <code>--first-parent</code> <code>master</code><code>..</code><code>seen</code> and look for the merge commit. The second | |
| parent of this commit is the tip of the topic branch.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>There is one guiding principle for choosing the right starting point: in | |
| general, always base your work on the oldest integration branch that | |
| your change is relevant to (see "Merge upwards" in | |
| <a href="gitworkflows.html">gitworkflows(7)</a>). What this principle means is that for the | |
| vast majority of cases, the starting point for new work should be the | |
| latest HEAD commit of <code>maint</code> or <code>master</code> based on the following cases:</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>If you are fixing bugs in the released version, use <code>maint</code> as the | |
| starting point (which may mean you have to fix things without using | |
| new API features on the cutting edge that recently appeared in | |
| <code>master</code> but were not available in the released version).</p> | |
| </li> | |
| <li> | |
| <p>Otherwise (such as if you are adding new features) use <code>master</code>.</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="admonitionblock note"> | |
| <table> | |
| <tr> | |
| <td class="icon"> | |
| <div class="title">Note</div> | |
| </td> | |
| <td class="content"> | |
| In exceptional cases, a bug that was introduced in an old | |
| version may have to be fixed for users of releases that are much older | |
| than the recent releases. <code>git</code> <code>describe</code> <code>--contains</code> <code>X</code> may describe | |
| <code>X</code> as <code>v2.30.0-rc2-gXXXXXX</code> for the commit <code>X</code> that introduced the | |
| bug, and the bug may be so high-impact that we may need to issue a new | |
| maintenance release for Git 2.30.x series, when "Git 2.41.0" is the | |
| current release. In such a case, you may want to use the tip of the | |
| maintenance branch for the 2.30.x series, which may be available in the | |
| <code>maint-2.30</code> branch in <a href="https://github.com/gitster/git">the maintainer’s | |
| "broken out" repo</a>. | |
| </td> | |
| </tr> | |
| </table> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This also means that <code>next</code> or <code>seen</code> are inappropriate starting points | |
| for your work, if you want your work to have a realistic chance of | |
| graduating to <code>master</code>. They are simply not designed to be used as a | |
| base for new work; they are only there to make sure that topics in | |
| flight work well together. This is why both <code>next</code> and <code>seen</code> are | |
| frequently re-integrated with incoming patches on the mailing list and | |
| force-pushed to replace previous versions of themselves. A topic that is | |
| literally built on top of <code>next</code> cannot be merged to <code>master</code> without | |
| dragging in all the other topics in <code>next</code>, some of which may not be | |
| ready.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>For example, if you are making tree-wide changes, while somebody else is | |
| also making their own tree-wide changes, your work may have severe | |
| overlap with the other person’s work. This situation may tempt you to | |
| use <code>next</code> as your starting point (because it would have the other | |
| person’s work included in it), but doing so would mean you’ll not only | |
| depend on the other person’s work, but all the other random things from | |
| other contributors that are already integrated into <code>next</code>. And as soon | |
| as <code>next</code> is updated with a new version, all of your work will need to | |
| be rebased anyway in order for them to be cleanly applied by the | |
| maintainer.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Under truly exceptional circumstances where you absolutely must depend | |
| on a select few topic branches that are already in <code>next</code> but not in | |
| <code>master</code>, you may want to create your own custom base-branch by forking | |
| <code>master</code> and merging the required topic branches into it. You could then | |
| work on top of this base-branch. But keep in mind that this base-branch | |
| would only be known privately to you. So when you are ready to send | |
| your patches to the list, be sure to communicate how you created it in | |
| your cover letter. This critical piece of information would allow | |
| others to recreate your base-branch on their end in order for them to | |
| try out your work.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Finally, note that some parts of the system have dedicated maintainers | |
| with their own separate source code repositories (see the section | |
| "Subsystems" below).</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="separate-commits">Make separate commits for logically separate changes.</h3> | |
| <div class="paragraph"> | |
| <p>Unless your patch is really trivial, you should not be sending | |
| out a patch that was generated between your working tree and | |
| your commit head. Instead, always make a commit with complete | |
| commit message and generate a series of patches from your | |
| repository. It is a good discipline.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Give an explanation for the change(s) that is detailed enough so | |
| that people can judge if it is good thing to do, without reading | |
| the actual patch text to determine how well the code does what | |
| the explanation promises to do.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If your description starts to get too long, that’s a sign that you | |
| probably need to split up your commit to finer grained pieces. | |
| That being said, patches which plainly describe the things that | |
| help reviewers check the patch, and future maintainers understand | |
| the code, are the most beautiful patches. Descriptions that summarize | |
| the point in the subject well, and describe the motivation for the | |
| change, the approach taken by the change, and if relevant how this | |
| differs substantially from the prior version, are all good things | |
| to have.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Make sure that you have tests for the bug you are fixing. See | |
| <code>t/README</code> for guidance.</p> | |
| </div> | |
| <div id="tests" class="paragraph"> | |
| <p>When adding a new feature, make sure that you have new tests to show | |
| the feature triggers the new behavior when it should, and to show the | |
| feature does not trigger when it shouldn’t. After any code change, | |
| make sure that the entire test suite passes. When fixing a bug, make | |
| sure you have new tests that break if somebody else breaks what you | |
| fixed by accident to avoid regression. Also, try merging your work to | |
| <em>next</em> and <em>seen</em> and make sure the tests still pass; topics by others | |
| that are still in flight may have unexpected interactions with what | |
| you are trying to do in your topic.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Pushing to a fork of <a href="https://github.com/git/git" class="bare">https://github.com/git/git</a> will use their CI | |
| integration to test your changes on Linux, Mac and Windows. See the | |
| <a href="#GHCI">GitHub CI</a> section for details.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Do not forget to update the documentation to describe the updated | |
| behavior and make sure that the resulting documentation set formats | |
| well (try the Documentation/doc-diff script).</p> | |
| </div> | |
| <div id="typofixes" class="paragraph"> | |
| <p>We currently have a liberal mixture of US and UK English norms for | |
| spelling and grammar, which is somewhat unfortunate. A huge patch that | |
| touches the files all over the place only to correct the inconsistency | |
| is not welcome, though. Potential clashes with other changes that can | |
| result from such a patch are not worth it. We prefer to gradually | |
| reconcile the inconsistencies in favor of US English, with small and | |
| easily digestible patches, as a side effect of doing some other real | |
| work in the vicinity (e.g. rewriting a paragraph for clarity, while | |
| turning en_UK spelling to en_US). Obvious typographical fixes are much | |
| more welcomed ("teh → "the"), preferably submitted as independent | |
| patches separate from other documentation changes.</p> | |
| </div> | |
| <div id="whitespace-check" class="paragraph"> | |
| <p>Oh, another thing. We are picky about whitespaces. Make sure your | |
| changes do not trigger errors with the sample pre-commit hook shipped | |
| in <code>templates/hooks--pre-commit</code>. To help ensure this does not happen, | |
| run <code>git</code> <code>diff</code> <code>--check</code> on your changes before you commit.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="describe-changes">Describe your changes well.</h3> | |
| <div class="paragraph"> | |
| <p>The log message that explains your changes is just as important as the | |
| changes themselves. Your code may be clearly written with in-code | |
| comment to sufficiently explain how it works with the surrounding | |
| code, but those who need to fix or enhance your code in the future | |
| will need to know <em>why</em> your code does what it does, for a few | |
| reasons:</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>Your code may be doing something differently from what you wanted it | |
| to do. Writing down what you actually wanted to achieve will help | |
| them fix your code and make it do what it should have been doing | |
| (also, you often discover your own bugs yourself, while writing the | |
| log message to summarize the thought behind it).</p> | |
| </li> | |
| <li> | |
| <p>Your code may be doing things that were only necessary for your | |
| immediate needs (e.g. "do X to directories" without implementing or | |
| even designing what is to be done on files). Writing down why you | |
| excluded what the code does not do will help guide future developers. | |
| Writing down "we do X to directories, because directories have | |
| characteristic Y" would help them infer "oh, files also have the same | |
| characteristic Y, so perhaps doing X to them would also make sense?". | |
| Saying "we don’t do the same X to files, because …​" will help them | |
| decide if the reasoning is sound (in which case they do not waste | |
| time extending your code to cover files), or reason differently (in | |
| which case, they can explain why they extend your code to cover | |
| files, too).</p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The goal of your log message is to convey the <em>why</em> behind your change | |
| to help future developers. The reviewers will also make sure that | |
| your proposed log message will serve this purpose well.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The first line of the commit message should be a short description (50 | |
| characters is the soft limit, see DISCUSSION in <a href="git-commit.html">git-commit(1)</a>), | |
| and should skip the full stop. It is also conventional in most cases to | |
| prefix the first line with "area: " where the area is a filename or | |
| identifier for the general area of the code being modified, e.g.</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>doc: clarify distinction between sign-off and pgp-signing</p> | |
| </li> | |
| <li> | |
| <p>githooks.txt: improve the intro section</p> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If in doubt which identifier to use, run <code>git</code> <code>log</code> <code>--no-merges</code> on the | |
| files you are modifying to see the current conventions.</p> | |
| </div> | |
| <div id="summary-section" class="paragraph"> | |
| <p>The title sentence after the "area:" prefix omits the full stop at the | |
| end, and its first word is not capitalized (the omission | |
| of capitalization applies only to the word after the "area:" | |
| prefix of the title) unless there is a reason to | |
| capitalize it other than because it is the first word in the sentence. | |
| E.g. "doc: clarify…​", not "doc: Clarify…​", or "githooks.txt: | |
| improve…​", not "githooks.txt: Improve…​". But "refs: HEAD is also | |
| treated as a ref" is correct, as we spell <code>HEAD</code> in all caps even when | |
| it appears in the middle of a sentence.</p> | |
| </div> | |
| <div id="meaningful-message" class="paragraph"> | |
| <p>The body should provide a meaningful commit message, which:</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>explains the problem the change tries to solve, i.e. what is wrong | |
| with the current code without the change.</p> | |
| </li> | |
| <li> | |
| <p>justifies the way the change solves the problem, i.e. why the | |
| result with the change is better.</p> | |
| </li> | |
| <li> | |
| <p>alternate solutions considered but discarded, if any.</p> | |
| </li> | |
| <li> | |
| <p>records the resolution of design or viability concerns raised by the | |
| community during the review, if any, ensuring the historical record | |
| explains why the chosen approach was accepted over alternatives.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div id="present-tense" class="paragraph"> | |
| <p>The problem statement that describes the status quo is written in the | |
| present tense. Write "The code does X when it is given input Y", | |
| instead of "The code used to do Y when given input X". You do not | |
| have to say "Currently"---the status quo in the problem statement is | |
| about the code <em>without</em> your change, by project convention.</p> | |
| </div> | |
| <div id="imperative-mood" class="paragraph"> | |
| <p>Describe your changes in imperative mood, e.g. "make xyzzy do frotz" | |
| instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy | |
| to do frotz", as if you are giving orders to the codebase to change | |
| its behavior. Try to make sure your explanation can be understood | |
| without external resources. Instead of giving a URL to a mailing list | |
| archive, summarize the relevant points of the discussion.</p> | |
| </div> | |
| <div id="commit-reference" class="paragraph"> | |
| <p>There are a few reasons why you may want to refer to another commit in | |
| the "more stable" part of the history (i.e. on branches like <code>maint</code>, | |
| <code>master</code>, and <code>next</code>):</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>A commit that introduced the root cause of a bug you are fixing.</p> | |
| </li> | |
| <li> | |
| <p>A commit that introduced a feature that you are enhancing.</p> | |
| </li> | |
| <li> | |
| <p>A commit that conflicts with your work when you made a trial merge | |
| of your work into <code>next</code> and <code>seen</code> for testing.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div class="paragraph"> | |
| <p>When you reference a commit on a more stable branch (like <code>master</code>, | |
| <code>maint</code> and <code>next</code>), use the format "abbreviated hash (subject, | |
| date)", like this:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30) | |
| noticed that ...</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The "Copy commit reference" command of gitk can be used to obtain this | |
| format (with the subject enclosed in a pair of double-quotes), or this | |
| invocation of <code>git</code> <code>show</code>:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> git show -s --pretty=reference <commit></pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>or, on an older version of Git without support for --pretty=reference:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> git show -s --date=short --pretty='format:%h (%s, %ad)' <commit></pre> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="sign-off">Certify your work by adding your <code>Signed-off-by:</code> trailer</h3> | |
| <div class="paragraph"> | |
| <p>To improve tracking of who did what, we ask you to certify that you | |
| wrote the patch or have the right to pass it on under the same license | |
| as ours, by "signing off" your patch. Without sign-off, we cannot | |
| accept your patches.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If (and only if) you certify the below D-C-O:</p> | |
| </div> | |
| <div id="dco" class="quoteblock"> | |
| <div class="title">Developer’s Certificate of Origin 1.1</div> | |
| <blockquote> | |
| <div class="paragraph"> | |
| <p>By making a contribution to this project, I certify that:</p> | |
| </div> | |
| <div class="olist loweralpha"> | |
| <ol class="loweralpha"> | |
| <li> | |
| <p>The contribution was created in whole or in part by me and I | |
| have the right to submit it under the open source license | |
| indicated in the file; or</p> | |
| </li> | |
| <li> | |
| <p>The contribution is based upon previous work that, to the best | |
| of my knowledge, is covered under an appropriate open source | |
| license and I have the right under that license to submit that | |
| work with modifications, whether created in whole or in part | |
| by me, under the same open source license (unless I am | |
| permitted to submit under a different license), as indicated | |
| in the file; or</p> | |
| </li> | |
| <li> | |
| <p>The contribution was provided directly to me by some other | |
| person who certified (a), (b) or (c) and I have not modified | |
| it.</p> | |
| </li> | |
| <li> | |
| <p>I understand and agree that this project and the contribution | |
| are public and that a record of the contribution (including all | |
| personal information I submit with it, including my sign-off) is | |
| maintained indefinitely and may be redistributed consistent with | |
| this project or the open source license(s) involved.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| </blockquote> | |
| </div> | |
| <div class="paragraph"> | |
| <p>you add a <code>Signed-off-by:</code> trailer to your commit, that looks like | |
| this:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> Signed-off-by: Random J Developer <random@developer.example.org></pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This line can be added by Git if you run the git-commit command with | |
| the -s option.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Notice that you can place your own <code>Signed-off-by:</code> trailer when | |
| forwarding somebody else’s patch with the above rules for | |
| D-C-O. Indeed you are encouraged to do so. Do not forget to | |
| place an in-body "From: " line at the beginning to properly attribute | |
| the change to its true author (see (2) above).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Place this <code>Signed-off-by:</code> trailer at the end, after trailers added by | |
| others and after other trailers added by you; see | |
| <a href="#commit-trailers">Commit trailers</a> below ("chronological order").</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This procedure originally came from the Linux kernel project, so our | |
| rule is quite similar to theirs, but what exactly it means to sign-off | |
| your patch differs from project to project, so it may be different | |
| from that of the project you are accustomed to.</p> | |
| </div> | |
| <div id="real-name" class="paragraph"> | |
| <p>Please use a known identity in the <code>Signed-off-by:</code> trailer, since we cannot | |
| accept anonymous contributions. It is common, but not required, to use some form | |
| of your real name. We realize that some contributors are not comfortable doing | |
| so or prefer to contribute under a pseudonym or preferred name and we can accept | |
| your patch either way, as long as the name and email you use are distinctive, | |
| identifying, and not misleading.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The goal of this policy is to allow us to have sufficient information to contact | |
| you if questions arise about your contribution.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="commit-trailers">Commit trailers</h3> | |
| <div class="paragraph"> | |
| <p>It is polite to credit people who have helped with your work to a | |
| substantial enough degree. This project uses commit trailers for that, | |
| where the credited person is written out like a Git author, i.e. with | |
| both their name and their email address. Note that the threshold to | |
| credit someone is a judgement call, and crediting someone for simple | |
| review work is certainly not necessary.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>These are the common trailers in use:</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p><code>Reported-by:</code> is used to credit someone who found the bug that | |
| the patch attempts to fix.</p> | |
| </li> | |
| <li> | |
| <p><code>Acked-by:</code> says that the person who is more familiar with the area | |
| the patch attempts to modify liked the patch.</p> | |
| </li> | |
| <li> | |
| <p><code>Reviewed-by:</code>, unlike the other trailers, can only be offered by the | |
| reviewers themselves when they are completely satisfied with the | |
| patch after a detailed analysis.</p> | |
| </li> | |
| <li> | |
| <p><code>Tested-by:</code> is used to indicate that the person applied the patch | |
| and found it to have the desired effect.</p> | |
| </li> | |
| <li> | |
| <p><code>Co-authored-by:</code> is used to indicate that people exchanged drafts | |
| of a patch before submitting it.</p> | |
| </li> | |
| <li> | |
| <p><code>Based-on-patch-by:</code> is used when someone else authored parts of the | |
| patch that you are submitting. This might be relevant if someone sent | |
| a patch to the mailing list with their sign-off. (Be mindful and ask | |
| them to sign off on it if they did not.)</p> | |
| </li> | |
| <li> | |
| <p><code>Helped-by:</code> is used to credit someone who suggested ideas for | |
| changes without providing the precise changes in patch form.</p> | |
| </li> | |
| <li> | |
| <p><code>Mentored-by:</code> is used to credit someone with helping develop a | |
| patch as part of a mentorship program (e.g., GSoC or Outreachy).</p> | |
| </li> | |
| <li> | |
| <p><code>Suggested-by:</code> is used to credit someone with suggesting the idea | |
| for a patch.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div class="paragraph"> | |
| <p>While you can also create your own trailer if the situation warrants it, we | |
| encourage you to instead use one of the common trailers in this project | |
| highlighted above.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Other projects might regularly refer to other kinds of data, like | |
| <code>Fixes:</code> and <code>Link:</code> in the Linux Kernel project, but these ones in | |
| particular are not used in this project.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Only capitalize the very first letter of the trailer, i.e. favor | |
| <code>Signed-off-by:</code> over <code>Signed-Off-By:</code> and <code>Acked-by:</code> over <code>Acked-By:</code>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>As mentioned under <a href="#dco">DCO</a> above, trailers are added in | |
| chronological order; one person might sign-off on a patch and send it to | |
| someone else, who then in turn adds her own sign-off. Further, any | |
| trailers that you add beyond your sign-off should come before that | |
| sign-off. That makes it clear what trailers which person added.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="cover-letter">Cover Letter</h3> | |
| <div class="paragraph"> | |
| <p>The purpose of your cover letter is to sell your changes, explain what | |
| they are about, and get your target audience interested enough to read | |
| the patches.</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>Every code change comes with risk of regression and maintenance cost. | |
| The cover letter should clearly communicate why the value of your | |
| proposed change is worth applying. You can also describe how the risk | |
| is reduced by the design choices you made while writing the patches.</p> | |
| </li> | |
| <li> | |
| <p>Make sure your target audience can understand what the patches are | |
| about and why they are needed without prior context.</p> | |
| </li> | |
| <li> | |
| <p>For a second or subsequent iteration of the same topic, make sure | |
| people who missed the earlier discussion can still understand what | |
| the patches are about, so they can judge if the topic is worth their | |
| time to read and comment on.</p> | |
| </li> | |
| <li> | |
| <p>To help those who are familiar with earlier iterations, give a | |
| summary of changes since the previous rounds.</p> | |
| </li> | |
| </ol> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="ai">Use of Artificial Intelligence (AI)</h3> | |
| <div class="paragraph"> | |
| <p>The Developer’s Certificate of Origin requires contributors to certify | |
| that they know the origin of their contributions to the project and | |
| that they have the right to submit it under the project’s license. | |
| It’s not yet clear that this can be legally satisfied when submitting | |
| significant amount of content that has been generated by AI tools.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Another issue with AI generated content is that AIs still often | |
| hallucinate or just produce bad code, commit messages, documentation | |
| or output, even when you point out their mistakes.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>To avoid these issues, we will reject anything that looks AI | |
| generated, that sounds overly formal or bloated, that looks like AI | |
| slop, that looks good on the surface but makes no sense, or that | |
| senders don’t understand or cannot explain.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>We strongly recommend using AI tools carefully and responsibly.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Contributors would often benefit more from AI by using it to guide and | |
| help them step by step towards producing a solution by themselves | |
| rather than by asking for a full solution that they would then mostly | |
| copy-paste. They can also use AI to help with debugging, or with | |
| checking for obvious mistakes, things that can be improved, things | |
| that don’t match our style, guidelines or our feedback, before sending | |
| it to us.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="git-tools">Generate your patch using Git tools out of your commits.</h3> | |
| <div class="paragraph"> | |
| <p>Git based diff tools generate unidiff which is the preferred format.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>You do not have to be afraid to use <code>-M</code> option to <code>git</code> <code>diff</code> or | |
| <code>git</code> <code>format-patch</code>, if your patch involves file renames. The | |
| receiving end can handle them just fine.</p> | |
| </div> | |
| <div id="review-patch" class="paragraph"> | |
| <p>Please make sure your patch does not add commented out debugging code, | |
| or include any extra files which do not relate to what your patch | |
| is trying to achieve. Make sure to review | |
| your patch after generating it, to ensure accuracy. Before | |
| sending out, please make sure it cleanly applies to the starting point you | |
| have chosen in the "Choose a starting point" section.</p> | |
| </div> | |
| <div class="admonitionblock note"> | |
| <table> | |
| <tr> | |
| <td class="icon"> | |
| <div class="title">Note</div> | |
| </td> | |
| <td class="content"> | |
| From the perspective of those reviewing your patch, the <code>master</code> | |
| branch is the default expected starting point. So if you have chosen a | |
| different starting point, please communicate this choice in your cover | |
| letter. | |
| </td> | |
| </tr> | |
| </table> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="send-patches">Sending your patches.</h3> | |
| <div class="sect3"> | |
| <h4 id="_choosing_your_reviewers">Choosing your reviewers</h4> | |
| <div class="admonitionblock note"> | |
| <table> | |
| <tr> | |
| <td class="icon"> | |
| <div class="title">Note</div> | |
| </td> | |
| <td class="content"> | |
| Patches that may be | |
| security relevant should be submitted privately to the Git Security | |
| mailing list<sup class="footnote" id="_footnote_security-ml">[<a id="_footnoteref_1" class="footnote" href="#_footnotedef_1" title="View footnote.">1</a>]</sup>, instead of the public mailing list. | |
| </td> | |
| </tr> | |
| </table> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Send your patch with "To:" set to the mailing list, with "cc:" listing | |
| people who are involved in the area you are touching (the <code>git-contacts</code> | |
| script in <code>contrib/contacts/</code><sup class="footnote" id="_footnote_contrib-scripts">[<a id="_footnoteref_2" class="footnote" href="#_footnotedef_2" title="View footnote.">2</a>]</sup> can help to | |
| identify them), to solicit comments and reviews. Also, when you made | |
| trial merges of your topic to <code>next</code> and <code>seen</code>, you may have noticed | |
| work by others conflicting with your changes. There is a good possibility | |
| that these people may know the area you are touching well.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If you are using <code>send-email</code>, you can feed it the output of <code>git-contacts</code> like | |
| this:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre> git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>After the list reached a consensus that it is a good idea to apply the | |
| patch, re-send it with "To:" set to the maintainer<sup class="footnote">[<a id="_footnoteref_3" class="footnote" href="#_footnotedef_3" title="View footnote.">3</a>]</sup> | |
| and "cc:" the list<sup class="footnote">[<a id="_footnoteref_4" class="footnote" href="#_footnotedef_4" title="View footnote.">4</a>]</sup> for inclusion. This is especially relevant | |
| when the maintainer did not heavily participate in the discussion and | |
| instead left the review to trusted others.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Do not forget to add trailers such as <code>Acked-by:</code>, <code>Reviewed-by:</code> and | |
| <code>Tested-by:</code> (see <a href="#commit-trailers">Commit trailers</a>), and "cc:" them | |
| when sending such a final version for inclusion.</p> | |
| </div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_format_patch_and_send_email"><code>format-patch</code> and <code>send-email</code></h4> | |
| <div class="paragraph"> | |
| <p>Learn to use <code>format-patch</code> and <code>send-email</code> if possible. These commands | |
| are optimized for the workflow of sending patches, avoiding many ways | |
| your existing e-mail client (often optimized for "multipart/*" MIME | |
| type e-mails) might render your patches unusable.</p> | |
| </div> | |
| <div class="admonitionblock note"> | |
| <table> | |
| <tr> | |
| <td class="icon"> | |
| <div class="title">Note</div> | |
| </td> | |
| <td class="content"> | |
| Here we outline the procedure using <code>format-patch</code> and | |
| <code>send-email</code>, but you can instead use GitGitGadget or <code>b4</code> to send in | |
| your patches (see <a href="MyFirstContribution.html">MyFirstContribution</a>). | |
| Contributors are encouraged to use <code>b4</code>, which automates much of the | |
| bookkeeping that is otherwise done by hand. | |
| </td> | |
| </tr> | |
| </table> | |
| </div> | |
| <div class="paragraph"> | |
| <p>People on the Git mailing list need to be able to read and | |
| comment on the changes you are submitting. It is important for | |
| a developer to be able to "quote" your changes, using standard | |
| e-mail tools, so that they may comment on specific portions of | |
| your code. For this reason, each patch should be submitted | |
| "inline" in a separate message.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>All subsequent versions of a patch series and other related patches should be | |
| grouped into their own e-mail thread to help readers find all parts of the | |
| series. To that end, send them as replies to either an additional "cover | |
| letter" message (see below), the first patch, or the respective preceding patch. | |
| Here is a <a href="MyFirstContribution.html#v2-git-send-email">step-by-step guide</a> on | |
| how to submit updated versions of a patch series. Before sending another | |
| version, make sure you have answered meaningful review comments in the existing | |
| discussion. Also give reviewers enough time to comment before sending another | |
| version.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If your log message (including your name on the | |
| <code>Signed-off-by:</code> trailer) is not writable in ASCII, make sure that | |
| you send off a message in the correct encoding.</p> | |
| </div> | |
| <div class="admonitionblock warning"> | |
| <table> | |
| <tr> | |
| <td class="icon"> | |
| <div class="title">Warning</div> | |
| </td> | |
| <td class="content"> | |
| Be wary of your MUAs word-wrap | |
| corrupting your patch. Do not cut-n-paste your patch; you can | |
| lose tabs that way if you are not careful. | |
| </td> | |
| </tr> | |
| </table> | |
| </div> | |
| <div class="paragraph"> | |
| <p>It is a common convention to prefix your subject line with | |
| [PATCH]. This lets people easily distinguish patches from other | |
| e-mail discussions. Use of markers in addition to PATCH within | |
| the brackets to describe the nature of the patch is also | |
| encouraged. E.g. [RFC PATCH] (where RFC stands for "request for | |
| comments") is often used to indicate a patch needs further | |
| discussion before being accepted, [PATCH v2], [PATCH v3] etc. | |
| are often seen when you are sending an update to what you have | |
| previously sent.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The <code>git</code> <code>format-patch</code> command follows the best current practice to | |
| format the body of an e-mail message. At the beginning of the | |
| patch should come your commit message, ending with the | |
| <code>Signed-off-by:</code> trailers, and a line that consists of three dashes, | |
| followed by the diffstat information and the patch itself. If | |
| you are forwarding a patch from somebody else, optionally, at | |
| the beginning of the e-mail message just before the commit | |
| message starts, you can put a "From: " line to name that person. | |
| To change the default "[PATCH]" in the subject to "[<text>]", use | |
| <code>git</code> <code>format-patch</code> <code>--subject-prefix=</code><em><text></em>. As a shortcut, you | |
| can use <code>--rfc</code> instead of <code>--subject-prefix=</code>"RFC <code>PATCH</code>", or | |
| <code>-v</code> <em><n></em> instead of <code>--subject-prefix=</code>"PATCH <code>v</code><em><n></em>".</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>You often want to add additional explanation about the patch, | |
| other than the commit message itself. Place such "cover letter" | |
| material between the three-dash line and the diffstat. For | |
| patches requiring multiple iterations of review and discussion, | |
| an explanation of changes between each iteration can be kept in | |
| Git-notes and inserted automatically following the three-dash | |
| line via <code>git</code> <code>format-patch</code> <code>--notes</code>.</p> | |
| </div> | |
| <div id="the-topic-summary" class="paragraph"> | |
| <p><strong>This is EXPERIMENTAL</strong>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>When sending a topic, you can optionally propose a topic name and/or a | |
| one-paragraph summary that should appear in the "What’s cooking" | |
| report when it is picked up to explain the topic. If you choose to do | |
| so, please write a 2-5 line paragraph that will fit well in our | |
| release notes (see many bulleted entries in the | |
| Documentation/RelNotes/* files for examples), and make it the first | |
| (or second, if including a suggested topic name) paragraph of the | |
| cover letter. If suggesting a topic name, use the format | |
| "XX/your-topic-name", where "XX" is a stand-in for the primary | |
| author’s initials, and "your-topic-name" is a brief, dash-delimited | |
| description of what your topic does. For a single-patch series, use | |
| the space between the three-dash line and the diffstat, as described | |
| earlier.</p> | |
| </div> | |
| <div id="multi-series-efforts" class="paragraph"> | |
| <p>If your patch series is part of a larger effort spanning multiple | |
| patch series, briefly describe the broader goal, and state where the | |
| current series fits into that goal. If you are suggesting a topic | |
| name as in <a href="#the-topic-summary">section above</a>, consider | |
| "XX/the-broader-goal-part-one", "XX/the-broader-goal-part-two", and so | |
| on.</p> | |
| </div> | |
| <div id="attachment" class="paragraph"> | |
| <p>Do not attach the patch as a MIME attachment, compressed or not. | |
| Do not let your e-mail client send quoted-printable. Do not let | |
| your e-mail client send format=flowed which would destroy | |
| whitespaces in your patches. Many | |
| popular e-mail applications will not always transmit a MIME | |
| attachment as plain text, making it impossible to comment on | |
| your code. A MIME attachment also takes a bit more time to | |
| process. This does not decrease the likelihood of your | |
| MIME-attached change being accepted, but it makes it more likely | |
| that it will be postponed.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Exception: If your mailer is mangling patches then someone may ask | |
| you to re-send them using MIME, that is OK.</p> | |
| </div> | |
| <div id="pgp-signature" class="paragraph"> | |
| <p>Do not PGP sign your patch. Most likely, your maintainer or other people on the | |
| list would not have your PGP key and would not bother obtaining it anyway. | |
| Your patch is not judged by who you are; a good patch from an unknown origin | |
| has a far better chance of being accepted than a patch from a known, respected | |
| origin that is done poorly or does incorrect things.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If you really really really really want to do a PGP signed | |
| patch, format it as "multipart/signed", not a text/plain message | |
| that starts with <code>-----BEGIN</code> <code>PGP</code> <code>SIGNED</code> <code>MESSAGE-----</code>. That is | |
| not a text/plain, it’s something else.</p> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_handling_conflicts_and_iterating_patches">Handling Conflicts and Iterating Patches</h3> | |
| <div class="paragraph"> | |
| <p>When revising changes made to your patches, it’s important to | |
| acknowledge the possibility of conflicts with other ongoing topics. To | |
| navigate these potential conflicts effectively, follow the recommended | |
| steps outlined below:</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>Build on a suitable base branch, see the <a href="#choose-starting-point">section above</a>, | |
| and format-patch the series. If you are doing "rebase -i" in-place to | |
| update from the previous round, this will reuse the previous base so | |
| (2) and (3) may become trivial.</p> | |
| </li> | |
| <li> | |
| <p>Find the base of where the last round was queued</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>$ mine='kn/ref-transaction-symref' | |
| $ git checkout "origin/seen^{/^Merge branch '$mine'}...master"</pre> | |
| </div> | |
| </div> | |
| </li> | |
| <li> | |
| <p>Apply your format-patch result. There are two cases</p> | |
| <div class="olist loweralpha"> | |
| <ol class="loweralpha" type="a"> | |
| <li> | |
| <p>Things apply cleanly and tests fine. Go to (4).</p> | |
| </li> | |
| <li> | |
| <p>Things apply cleanly but does not build or test fails, or things do | |
| not apply cleanly.</p> | |
| <div class="paragraph"> | |
| <p>In the latter case, you have textual or semantic conflicts coming from | |
| the difference between the old base and the base you used to build in | |
| (1). Identify what caused the breakages (e.g., a topic or two may have | |
| merged since the base used by (2) until the base used by (1)).</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Check out the latest <em>origin/master</em> (which may be newer than the base | |
| used by (2)), "merge --no-ff" the topics you newly depend on in there, | |
| and use the result of the merge(s) as the base, rebuild the series and | |
| test again. Run format-patch from the last such merges to the tip of | |
| your topic. If you did</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>$ git checkout origin/master | |
| $ git merge --no-ff --into-name kn/ref-transaction-symref fo/obar | |
| $ git merge --no-ff --into-name kn/ref-transaction-symref ba/zqux | |
| ... rebuild the topic ...</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Then you’d just format your topic above these "preparing the ground" | |
| merges, e.g.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>$ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Do not forget to write in the cover letter you did this, including the | |
| topics you have in your base on top of <em>master</em>. Then go to (4).</p> | |
| </div> | |
| </li> | |
| </ol> | |
| </div> | |
| </li> | |
| <li> | |
| <p>Make a trial merge of your topic into <em>next</em> and <em>seen</em>, e.g.</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>$ git checkout --detach 'origin/seen' | |
| $ git revert -m 1 <the merge of the previous iteration into seen> | |
| $ git merge kn/ref-transaction-symref</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>The "revert" is needed if the previous iteration of your topic is | |
| already in <em>seen</em> (like in this case). You could choose to rebuild | |
| master..origin/seen from scratch while excluding your previous | |
| iteration, which may emulate what happens on the maintainers end more | |
| closely.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This trial merge may conflict. It is primarily to see what conflicts | |
| <em>other</em> topics may have with your topic. In other words, you do not | |
| have to depend on it to make your topic work on <em>master</em>. It may | |
| become the job of the other topic owners to resolve conflicts if your | |
| topic goes to <em>next</em> before theirs.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Make a note on what conflict you saw in the cover letter. You do not | |
| necessarily have to resolve them, but it would be a good opportunity to | |
| learn what others are doing in related areas.</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>$ git checkout --detach 'origin/next' | |
| $ git merge kn/ref-transaction-symref</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>This is to see what conflicts your topic has with other topics that are | |
| already cooking. This should not conflict if (3)-2 prepared a base on | |
| top of updated master plus dependent topics taken from <em>next</em>. Unless | |
| the context is severe (one way to tell is try the same trial merge with | |
| your old iteration, which may conflict in a similar way), expect that it | |
| will be handled on maintainers end (if it gets unmanageable, I’ll ask to | |
| rebase when I receive your patches).</p> | |
| </div> | |
| </li> | |
| </ol> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_subsystems_with_dedicated_maintainers">Subsystems with dedicated maintainers</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>Some parts of the system have dedicated maintainers with their own | |
| repositories.</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p><code>git-gui/</code> comes from the git-gui project, maintained by Johannes Sixt:</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>https://github.com/j6t/git-gui</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>Contibutions should go via the git mailing list.</pre> | |
| </div> | |
| </div> | |
| </li> | |
| <li> | |
| <p><code>gitk-git/</code> comes from the gitk project, maintained by Johannes Sixt:</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>https://github.com/j6t/gitk</pre> | |
| </div> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>Contibutions should go via the git mailing list.</pre> | |
| </div> | |
| </div> | |
| </li> | |
| <li> | |
| <p><code>po/</code> comes from the localization coordinator, Jiang Xin:</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>https://github.com/git-l10n/git-po/</pre> | |
| </div> | |
| </div> | |
| </li> | |
| </ul> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Patches to these parts should be based on their trees.</p> | |
| </div> | |
| <div class="ulist"> | |
| <ul> | |
| <li> | |
| <p>The "Git documentation translations" project, led by Jean-Noël | |
| Avila, translates our documentation pages. Their work products are | |
| maintained separately from this project, not as part of our tree:</p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>https://github.com/jnavila/git-manpages-l10n/</pre> | |
| </div> | |
| </div> | |
| </li> | |
| </ul> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_github_ci">GitHub CI<a id="GHCI"></a></h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>With an account at GitHub, you can use GitHub CI to test your changes | |
| on Linux, Mac and Windows. See | |
| <a href="https://github.com/git/git/actions/workflows/main.yml" class="bare">https://github.com/git/git/actions/workflows/main.yml</a> for examples of | |
| recent CI runs.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Follow these steps for the initial setup:</p> | |
| </div> | |
| <div class="olist arabic"> | |
| <ol class="arabic"> | |
| <li> | |
| <p>Fork <a href="https://github.com/git/git" class="bare">https://github.com/git/git</a> to your GitHub account. | |
| You can find detailed instructions how to fork here: | |
| <a href="https://help.github.com/articles/fork-a-repo/" class="bare">https://help.github.com/articles/fork-a-repo/</a></p> | |
| </li> | |
| </ol> | |
| </div> | |
| <div class="paragraph"> | |
| <p>After the initial setup, CI will run whenever you push new changes | |
| to your fork of Git on GitHub. You can monitor the test state of all your | |
| branches here: <code>https://github.com/</code><Your <code>GitHub</code> <code>handle</code>><code>/git/actions/workflows/main.yml</code></p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>If a branch does not pass all test cases then it will be marked with a | |
| red <code>x</code>, instead of a green check. In that case, you can click on the | |
| failing job and navigate to "ci/run-build-and-tests.sh" and/or | |
| "ci/print-test-failures.sh". You can also download "Artifacts" which | |
| are zip archives containing tarred (or zipped) archives with test data | |
| relevant for debugging.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Then fix the problem and push your fix to your GitHub fork. This will | |
| trigger a new CI build to ensure all tests pass.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>Even if you do not use GitHub CI to test your changes, pay close | |
| attention to new failures on the branches when the maintainer pushes | |
| out after your topic gets merged to the <em>seen</em> branch to make sure | |
| that your topic is not breaking the CI, and retract your breaking | |
| topic quickly while you fix the breakage you caused.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>To see maintainer’s push, keep an eye on this page:</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>`https://github.com/git/git/actions/workflows/main.yml?query=event%3Apush+actor%3Agitster`</pre> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="mua">MUA specific hints</h2> | |
| <div class="sectionbody"> | |
| <div class="paragraph"> | |
| <p>Some of the patches I receive or pick up from the list share common | |
| patterns of breakage. Please make sure your MUA is set up | |
| properly not to corrupt whitespaces.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>See the DISCUSSION section of <a href="git-format-patch.html">git-format-patch(1)</a> for hints on | |
| checking your patch by mailing it to yourself and applying with | |
| <a href="git-am.html">git-am(1)</a>.</p> | |
| </div> | |
| <div class="paragraph"> | |
| <p>While you are at it, check the resulting commit log message from | |
| a trial run of applying the patch. If what is in the resulting | |
| commit is not exactly what you would want to see, it is very | |
| likely that your maintainer would end up hand editing the log | |
| message when he applies your patch. Things like "Hi, this is my | |
| first patch.\n", if you really want to put in the patch e-mail, | |
| should come after the three-dash line that signals the end of the | |
| commit message.</p> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_pine">Pine</h3> | |
| <div class="paragraph"> | |
| <p>(Johannes Schindelin)</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>I don't know how many people still use pine, but for those poor | |
| souls it may be good to mention that the quell-flowed-text is | |
| needed for recent versions. | |
| ... the "no-strip-whitespace-before-send" option, too. AFAIK it | |
| was introduced in 4.60.</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>(Linus Torvalds)</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>And 4.58 needs at least this. | |
| diff-tree 8326dd8350be64ac7fc805f6563a1d61ad10d32c (from e886a61f76edf5410573e92e38ce22974f9c40f1) | |
| Author: Linus Torvalds <torvalds@g5.osdl.org> | |
| Date: Mon Aug 15 17:23:51 2005 -0700 | |
| Fix pine whitespace-corruption bug | |
| There's no excuse for unconditionally removing whitespace from | |
| the pico buffers on close. | |
| diff --git a/pico/pico.c b/pico/pico.c | |
| --- a/pico/pico.c | |
| +++ b/pico/pico.c | |
| @@ -219,7 +219,9 @@ PICO *pm; | |
| switch(pico_all_done){ /* prepare for/handle final events */ | |
| case COMP_EXIT : /* already confirmed */ | |
| packheader(); | |
| +#if 0 | |
| stripwhitespace(); | |
| +#endif | |
| c |= COMP_EXIT; | |
| break;</pre> | |
| </div> | |
| </div> | |
| <div class="paragraph"> | |
| <p>(Daniel Barkalow)</p> | |
| </div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre>> A patch to SubmittingPatches, MUA specific help section for | |
| > users of Pine 4.63 would be very much appreciated. | |
| Ah, it looks like a recent version changed the default behavior to do the | |
| right thing, and inverted the sense of the configuration option. (Either | |
| that or Gentoo did it.) So you need to set the | |
| "no-strip-whitespace-before-send" option, unless the option you have is | |
| "strip-whitespace-before-send", in which case you should avoid checking | |
| it.</pre> | |
| </div> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_thunderbird_kmail_gmail">Thunderbird, KMail, GMail</h3> | |
| <div class="paragraph"> | |
| <p>See the MUA-SPECIFIC HINTS section of <a href="git-format-patch.html">git-format-patch(1)</a>.</p> | |
| </div> | |
| </div> | |
| <div class="sect2"> | |
| <h3 id="_gnus">Gnus</h3> | |
| <div class="paragraph"> | |
| <p>"|" in the <code>*Summary*</code> buffer can be used to pipe the current | |
| message to an external program, and this is a handy way to drive | |
| <code>git</code> <code>am</code>. However, if the message is MIME encoded, what is | |
| piped into the program is the representation you see in your | |
| <code>*Article*</code> buffer after unwrapping MIME. This is often not what | |
| you would want for two reasons. It tends to screw up non-ASCII | |
| characters (most notably in people’s names), and also | |
| whitespaces (fatal in patches). Running "C-u g" to display the | |
| message in raw form before using "|" to run the pipe can work | |
| this problem around.</p> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| </div> | |
| <div id="footnotes"> | |
| <hr/> | |
| <div class="footnote" id="_footnotedef_1"> | |
| <a href="#_footnoteref_1">1</a>. The Git Security mailing list: <a href="mailto:git-security@googlegroups.com">git-security@googlegroups.com</a> | |
| </div> | |
| <div class="footnote" id="_footnotedef_2"> | |
| <a href="#_footnoteref_2">2</a>. Scripts under `contrib/` are not part of the core `git` binary and must be called directly. Clone the Git codebase and run `perl contrib/contacts/git-contacts`. | |
| </div> | |
| <div class="footnote" id="_footnotedef_3"> | |
| <a href="#_footnoteref_3">3</a>. The current maintainer: <a href="mailto:gitster@pobox.com">gitster@pobox.com</a> | |
| </div> | |
| <div class="footnote" id="_footnotedef_4"> | |
| <a href="#_footnoteref_4">4</a>. The mailing list: <a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a> | |
| </div> | |
| </div> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated 2026-07-19 12:35:44 -0700 | |
| </div> | |
| </div> | |
| </body> | |
| </html> |