| <?xml version="1.0" encoding="UTF-8"?> | |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" | |
| "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> | |
| <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> | |
| <head> | |
| <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" /> | |
| <meta name="generator" content="AsciiDoc 10.2.0" /> | |
| <title>Submitting Patches</title> | |
| <style type="text/css"> | |
| /* Shared CSS for AsciiDoc xhtml11 and html5 backends */ | |
| /* Default font. */ | |
| body { | |
| font-family: Georgia,serif; | |
| } | |
| /* Title font. */ | |
| h1, h2, h3, h4, h5, h6, | |
| div.title, caption.title, | |
| thead, p.table.header, | |
| #toctitle, | |
| #author, #revnumber, #revdate, #revremark, | |
| #footer { | |
| font-family: Arial,Helvetica,sans-serif; | |
| } | |
| body { | |
| margin: 1em 5% 1em 5%; | |
| } | |
| a { | |
| color: blue; | |
| text-decoration: underline; | |
| } | |
| a:visited { | |
| color: fuchsia; | |
| } | |
| em { | |
| font-style: italic; | |
| color: navy; | |
| } | |
| strong { | |
| font-weight: bold; | |
| color: #083194; | |
| } | |
| h1, h2, h3, h4, h5, h6 { | |
| color: #527bbd; | |
| margin-top: 1.2em; | |
| margin-bottom: 0.5em; | |
| line-height: 1.3; | |
| } | |
| h1, h2, h3 { | |
| border-bottom: 2px solid silver; | |
| } | |
| h2 { | |
| padding-top: 0.5em; | |
| } | |
| h3 { | |
| float: left; | |
| } | |
| h3 + * { | |
| clear: left; | |
| } | |
| h5 { | |
| font-size: 1.0em; | |
| } | |
| div.sectionbody { | |
| margin-left: 0; | |
| } | |
| hr { | |
| border: 1px solid silver; | |
| } | |
| p { | |
| margin-top: 0.5em; | |
| margin-bottom: 0.5em; | |
| } | |
| ul, ol, li > p { | |
| margin-top: 0; | |
| } | |
| ul > li { color: #aaa; } | |
| ul > li > * { color: black; } | |
| .monospaced, code, pre { | |
| font-family: "Courier New", Courier, monospace; | |
| font-size: inherit; | |
| color: navy; | |
| padding: 0; | |
| margin: 0; | |
| } | |
| pre { | |
| white-space: pre-wrap; | |
| } | |
| #author { | |
| color: #527bbd; | |
| font-weight: bold; | |
| font-size: 1.1em; | |
| } | |
| #email { | |
| } | |
| #revnumber, #revdate, #revremark { | |
| } | |
| #footer { | |
| font-size: small; | |
| border-top: 2px solid silver; | |
| padding-top: 0.5em; | |
| margin-top: 4.0em; | |
| } | |
| #footer-text { | |
| float: left; | |
| padding-bottom: 0.5em; | |
| } | |
| #footer-badges { | |
| float: right; | |
| padding-bottom: 0.5em; | |
| } | |
| #preamble { | |
| margin-top: 1.5em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.imageblock, div.exampleblock, div.verseblock, | |
| div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock, | |
| div.admonitionblock { | |
| margin-top: 1.0em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.admonitionblock { | |
| margin-top: 2.0em; | |
| margin-bottom: 2.0em; | |
| margin-right: 10%; | |
| color: #606060; | |
| } | |
| div.content { /* Block element content. */ | |
| padding: 0; | |
| } | |
| /* Block element titles. */ | |
| div.title, caption.title { | |
| color: #527bbd; | |
| font-weight: bold; | |
| text-align: left; | |
| margin-top: 1.0em; | |
| margin-bottom: 0.5em; | |
| } | |
| div.title + * { | |
| margin-top: 0; | |
| } | |
| td div.title:first-child { | |
| margin-top: 0.0em; | |
| } | |
| div.content div.title:first-child { | |
| margin-top: 0.0em; | |
| } | |
| div.content + div.title { | |
| margin-top: 0.0em; | |
| } | |
| div.sidebarblock > div.content { | |
| background: #ffffee; | |
| border: 1px solid #dddddd; | |
| border-left: 4px solid #f0f0f0; | |
| padding: 0.5em; | |
| } | |
| div.listingblock > div.content { | |
| border: 1px solid #dddddd; | |
| border-left: 5px solid #f0f0f0; | |
| background: #f8f8f8; | |
| padding: 0.5em; | |
| } | |
| div.quoteblock, div.verseblock { | |
| padding-left: 1.0em; | |
| margin-left: 1.0em; | |
| margin-right: 10%; | |
| border-left: 5px solid #f0f0f0; | |
| color: #888; | |
| } | |
| div.quoteblock > div.attribution { | |
| padding-top: 0.5em; | |
| text-align: right; | |
| } | |
| div.verseblock > pre.content { | |
| font-family: inherit; | |
| font-size: inherit; | |
| } | |
| div.verseblock > div.attribution { | |
| padding-top: 0.75em; | |
| text-align: left; | |
| } | |
| /* DEPRECATED: Pre version 8.2.7 verse style literal block. */ | |
| div.verseblock + div.attribution { | |
| text-align: left; | |
| } | |
| div.admonitionblock .icon { | |
| vertical-align: top; | |
| font-size: 1.1em; | |
| font-weight: bold; | |
| text-decoration: underline; | |
| color: #527bbd; | |
| padding-right: 0.5em; | |
| } | |
| div.admonitionblock td.content { | |
| padding-left: 0.5em; | |
| border-left: 3px solid #dddddd; | |
| } | |
| div.exampleblock > div.content { | |
| border-left: 3px solid #dddddd; | |
| padding-left: 0.5em; | |
| } | |
| div.imageblock div.content { padding-left: 0; } | |
| span.image img { border-style: none; vertical-align: text-bottom; } | |
| a.image:visited { color: white; } | |
| dl { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| dt { | |
| margin-top: 0.5em; | |
| margin-bottom: 0; | |
| font-style: normal; | |
| color: navy; | |
| } | |
| dd > *:first-child { | |
| margin-top: 0.1em; | |
| } | |
| ul, ol { | |
| list-style-position: outside; | |
| } | |
| ol.arabic { | |
| list-style-type: decimal; | |
| } | |
| 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; | |
| } | |
| div.compact ul, div.compact ol, | |
| div.compact p, div.compact p, | |
| div.compact div, div.compact div { | |
| margin-top: 0.1em; | |
| margin-bottom: 0.1em; | |
| } | |
| tfoot { | |
| font-weight: bold; | |
| } | |
| td > div.verse { | |
| white-space: pre; | |
| } | |
| div.hdlist { | |
| margin-top: 0.8em; | |
| margin-bottom: 0.8em; | |
| } | |
| div.hdlist tr { | |
| padding-bottom: 15px; | |
| } | |
| dt.hdlist1.strong, td.hdlist1.strong { | |
| font-weight: bold; | |
| } | |
| td.hdlist1 { | |
| vertical-align: top; | |
| font-style: normal; | |
| padding-right: 0.8em; | |
| color: navy; | |
| } | |
| td.hdlist2 { | |
| vertical-align: top; | |
| } | |
| div.hdlist.compact tr { | |
| margin: 0; | |
| padding-bottom: 0; | |
| } | |
| .comment { | |
| background: yellow; | |
| } | |
| .footnote, .footnoteref { | |
| font-size: 0.8em; | |
| } | |
| span.footnote, span.footnoteref { | |
| vertical-align: super; | |
| } | |
| #footnotes { | |
| margin: 20px 0 20px 0; | |
| padding: 7px 0 0 0; | |
| } | |
| #footnotes div.footnote { | |
| margin: 0 0 5px 0; | |
| } | |
| #footnotes hr { | |
| border: none; | |
| border-top: 1px solid silver; | |
| height: 1px; | |
| text-align: left; | |
| margin-left: 0; | |
| width: 20%; | |
| min-width: 100px; | |
| } | |
| div.colist td { | |
| padding-right: 0.5em; | |
| padding-bottom: 0.3em; | |
| vertical-align: top; | |
| } | |
| div.colist td img { | |
| margin-top: 0.3em; | |
| } | |
| @media print { | |
| #footer-badges { display: none; } | |
| } | |
| #toc { | |
| margin-bottom: 2.5em; | |
| } | |
| #toctitle { | |
| color: #527bbd; | |
| font-size: 1.1em; | |
| font-weight: bold; | |
| margin-top: 1.0em; | |
| margin-bottom: 0.1em; | |
| } | |
| div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 { | |
| margin-top: 0; | |
| margin-bottom: 0; | |
| } | |
| div.toclevel2 { | |
| margin-left: 2em; | |
| font-size: 0.9em; | |
| } | |
| div.toclevel3 { | |
| margin-left: 4em; | |
| font-size: 0.9em; | |
| } | |
| div.toclevel4 { | |
| margin-left: 6em; | |
| font-size: 0.9em; | |
| } | |
| span.aqua { color: aqua; } | |
| span.black { color: black; } | |
| span.blue { color: blue; } | |
| span.fuchsia { color: fuchsia; } | |
| span.gray { color: gray; } | |
| span.green { color: green; } | |
| span.lime { color: lime; } | |
| span.maroon { color: maroon; } | |
| span.navy { color: navy; } | |
| span.olive { color: olive; } | |
| span.purple { color: purple; } | |
| span.red { color: red; } | |
| span.silver { color: silver; } | |
| span.teal { color: teal; } | |
| span.white { color: white; } | |
| span.yellow { color: yellow; } | |
| span.aqua-background { background: aqua; } | |
| span.black-background { background: black; } | |
| span.blue-background { background: blue; } | |
| span.fuchsia-background { background: fuchsia; } | |
| span.gray-background { background: gray; } | |
| span.green-background { background: green; } | |
| span.lime-background { background: lime; } | |
| span.maroon-background { background: maroon; } | |
| span.navy-background { background: navy; } | |
| span.olive-background { background: olive; } | |
| span.purple-background { background: purple; } | |
| span.red-background { background: red; } | |
| span.silver-background { background: silver; } | |
| span.teal-background { background: teal; } | |
| span.white-background { background: white; } | |
| span.yellow-background { background: yellow; } | |
| span.big { font-size: 2em; } | |
| span.small { font-size: 0.6em; } | |
| span.underline { text-decoration: underline; } | |
| span.overline { text-decoration: overline; } | |
| span.line-through { text-decoration: line-through; } | |
| div.unbreakable { page-break-inside: avoid; } | |
| /* | |
| * xhtml11 specific | |
| * | |
| * */ | |
| div.tableblock { | |
| margin-top: 1.0em; | |
| margin-bottom: 1.5em; | |
| } | |
| div.tableblock > table { | |
| border: 3px solid #527bbd; | |
| } | |
| thead, p.table.header { | |
| font-weight: bold; | |
| color: #527bbd; | |
| } | |
| p.table { | |
| margin-top: 0; | |
| } | |
| /* Because the table frame attribute is overridden by CSS in most browsers. */ | |
| div.tableblock > table[frame="void"] { | |
| border-style: none; | |
| } | |
| div.tableblock > table[frame="hsides"] { | |
| border-left-style: none; | |
| border-right-style: none; | |
| } | |
| div.tableblock > table[frame="vsides"] { | |
| border-top-style: none; | |
| border-bottom-style: none; | |
| } | |
| /* | |
| * html5 specific | |
| * | |
| * */ | |
| table.tableblock { | |
| margin-top: 1.0em; | |
| margin-bottom: 1.5em; | |
| } | |
| thead, p.tableblock.header { | |
| font-weight: bold; | |
| color: #527bbd; | |
| } | |
| p.tableblock { | |
| margin-top: 0; | |
| } | |
| table.tableblock { | |
| border-width: 3px; | |
| border-spacing: 0px; | |
| border-style: solid; | |
| border-color: #527bbd; | |
| border-collapse: collapse; | |
| } | |
| th.tableblock, td.tableblock { | |
| border-width: 1px; | |
| padding: 4px; | |
| border-style: solid; | |
| border-color: #527bbd; | |
| } | |
| table.tableblock.frame-topbot { | |
| border-left-style: hidden; | |
| border-right-style: hidden; | |
| } | |
| table.tableblock.frame-sides { | |
| border-top-style: hidden; | |
| border-bottom-style: hidden; | |
| } | |
| table.tableblock.frame-none { | |
| border-style: hidden; | |
| } | |
| th.tableblock.halign-left, td.tableblock.halign-left { | |
| text-align: left; | |
| } | |
| th.tableblock.halign-center, td.tableblock.halign-center { | |
| text-align: center; | |
| } | |
| th.tableblock.halign-right, td.tableblock.halign-right { | |
| text-align: right; | |
| } | |
| th.tableblock.valign-top, td.tableblock.valign-top { | |
| vertical-align: top; | |
| } | |
| th.tableblock.valign-middle, td.tableblock.valign-middle { | |
| vertical-align: middle; | |
| } | |
| th.tableblock.valign-bottom, td.tableblock.valign-bottom { | |
| vertical-align: bottom; | |
| } | |
| /* | |
| * manpage specific | |
| * | |
| * */ | |
| body.manpage h1 { | |
| padding-top: 0.5em; | |
| padding-bottom: 0.5em; | |
| border-top: 2px solid silver; | |
| border-bottom: 2px solid silver; | |
| } | |
| body.manpage h2 { | |
| border-style: none; | |
| } | |
| body.manpage div.sectionbody { | |
| margin-left: 3em; | |
| } | |
| @media print { | |
| body.manpage div#toc { display: none; } | |
| } | |
| </style> | |
| <script type="text/javascript"> | |
| /*<+'])'); | |
| // Function that scans the DOM tree for header elements (the DOM2 | |
| // nodeIterator API would be a better technique but not supported by all | |
| // browsers). | |
| var iterate = function (el) { | |
| for (var i = el.firstChild; i != null; i = i.nextSibling) { | |
| if (i.nodeType == 1 /* Node.ELEMENT_NODE */) { | |
| var mo = re.exec(i.tagName); | |
| if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") { | |
| result[result.length] = new TocEntry(i, getText(i), mo[1]-1); | |
| } | |
| iterate(i); | |
| } | |
| } | |
| } | |
| iterate(el); | |
| return result; | |
| } | |
| var toc = document.getElementById("toc"); | |
| if (!toc) { | |
| return; | |
| } | |
| // Delete existing TOC entries in case we're reloading the TOC. | |
| var tocEntriesToRemove = []; | |
| var i; | |
| for (i = 0; i < toc.childNodes.length; i++) { | |
| var entry = toc.childNodes[i]; | |
| if (entry.nodeName.toLowerCase() == 'div' | |
| && entry.getAttribute("class") | |
| && entry.getAttribute("class").match(/^toclevel/)) | |
| tocEntriesToRemove.push(entry); | |
| } | |
| for (i = 0; i < tocEntriesToRemove.length; i++) { | |
| toc.removeChild(tocEntriesToRemove[i]); | |
| } | |
| // Rebuild TOC entries. | |
| var entries = tocEntries(document.getElementById("content"), toclevels); | |
| for (var i = 0; i < entries.length; ++i) { | |
| var entry = entries[i]; | |
| if (entry.element.id == "") | |
| entry.element.id = "_toc_" + i; | |
| var a = document.createElement("a"); | |
| a.href = "#" + entry.element.id; | |
| a.appendChild(document.createTextNode(entry.text)); | |
| var div = document.createElement("div"); | |
| div.appendChild(a); | |
| div.className = "toclevel" + entry.toclevel; | |
| toc.appendChild(div); | |
| } | |
| if (entries.length == 0) | |
| toc.parentNode.removeChild(toc); | |
| }, | |
| ///////////////////////////////////////////////////////////////////// | |
| // Footnotes generator | |
| ///////////////////////////////////////////////////////////////////// | |
| /* Based on footnote generation code from: | |
| * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html | |
| */ | |
| footnotes: function () { | |
| // Delete existing footnote entries in case we're reloading the footnodes. | |
| var i; | |
| var noteholder = document.getElementById("footnotes"); | |
| if (!noteholder) { | |
| return; | |
| } | |
| var entriesToRemove = []; | |
| for (i = 0; i < noteholder.childNodes.length; i++) { | |
| var entry = noteholder.childNodes[i]; | |
| if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote") | |
| entriesToRemove.push(entry); | |
| } | |
| for (i = 0; i < entriesToRemove.length; i++) { | |
| noteholder.removeChild(entriesToRemove[i]); | |
| } | |
| // Rebuild footnote entries. | |
| var cont = document.getElementById("content"); | |
| var spans = cont.getElementsByTagName("span"); | |
| var refs = {}; | |
| var n = 0; | |
| for (i=0; i<spans.length; i++) { | |
| if (spans[i].className == "footnote") { | |
| n++; | |
| var note = spans[i].getAttribute("data-note"); | |
| if (!note) { | |
| // Use [\s\S] in place of . so multi-line matches work. | |
| // Because JavaScript has no s (dotall) regex flag. | |
| note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1]; | |
| spans[i].innerHTML = | |
| "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n + | |
| "' title='View footnote' class='footnote'>" + n + "</a>]"; | |
| spans[i].setAttribute("data-note", note); | |
| } | |
| noteholder.innerHTML += | |
| "<div class='footnote' id='_footnote_" + n + "'>" + | |
| "<a href='#_footnoteref_" + n + "' title='Return to text'>" + | |
| n + "</a>. " + note + "</div>"; | |
| var id =spans[i].getAttribute("id"); | |
| if (id != null) refs["#"+id] = n; | |
| } | |
| } | |
| if (n == 0) | |
| noteholder.parentNode.removeChild(noteholder); | |
| else { | |
| // Process footnoterefs. | |
| for (i=0; i<spans.length; i++) { | |
| if (spans[i].className == "footnoteref") { | |
| var href = spans[i].getElementsByTagName("a")[0].getAttribute("href"); | |
| href = href.match(/#.*/)[0]; // Because IE return full URL. | |
| n = refs[href]; | |
| spans[i].innerHTML = | |
| "[<a href='#_footnote_" + n + | |
| "' title='View footnote' class='footnote'>" + n + "</a>]"; | |
| } | |
| } | |
| } | |
| }, | |
| install: function(toclevels) { | |
| var timerId; | |
| function reinstall() { | |
| asciidoc.footnotes(); | |
| if (toclevels) { | |
| asciidoc.toc(toclevels); | |
| } | |
| } | |
| function reinstallAndRemoveTimer() { | |
| clearInterval(timerId); | |
| reinstall(); | |
| } | |
| timerId = setInterval(reinstall, 500); | |
| if (document.addEventListener) | |
| document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false); | |
| else | |
| window.onload = reinstallAndRemoveTimer; | |
| } | |
| } | |
| asciidoc.install(); | |
| /*]]>*/ | |
| </script> | |
| </head> | |
| <body class="article"> | |
| <div id="header"> | |
| <h1>Submitting Patches</h1> | |
| <span id="revdate">2024-07-17</span> | |
| </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 log -p -- <em>$area_you_are_modifying</em></code> would | |
| help you find out who they are.</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, while taking | |
| them into account while preparing an updated set of patches. | |
| </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 wait to become part | |
| of the next major release. | |
| </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 log | |
| --first-parent master..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"> | |
| <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 describe --contains 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 class="paragraph" id="tests"><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">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 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 class="paragraph" id="whitespace-check"><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 diff --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 log --no-merges</code> on the | |
| files you are modifying to see the current conventions.</p></div> | |
| <div class="paragraph" id="summary-section"><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 class="paragraph" id="meaningful-message"><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> | |
| </ol></div> | |
| <div class="paragraph" id="present-tense"><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 class="paragraph" id="imperative-mood"><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 class="paragraph" id="commit-reference"><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><code> Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30) | |
| noticed that ...</code></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 show</code>:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code> git show -s --pretty=reference <commit></code></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><code> git show -s --date=short --pretty='format:%h (%s, %ad)' <commit></code></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 class="quoteblock" id="dco"> | |
| <div class="title">Developer’s Certificate of Origin 1.1</div> | |
| <div class="content"> | |
| <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> | |
| </div> | |
| <div class="attribution"> | |
| </div></div> | |
| <div class="paragraph"><p>you add a "Signed-off-by" trailer to your commit, that looks like | |
| this:</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code> Signed-off-by: Random J Developer <random@developer.example.org></code></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>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 class="paragraph" id="real-name"><p>Also notice that a real name is used in the <code>Signed-off-by</code> trailer. Please | |
| don’t hide your real name.</p></div> | |
| <div class="paragraph" id="commit-trailers"><p>If you like, you can put extra tags at the end:</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 tags, 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>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>Only capitalize the very first letter of tags, i.e. favor | |
| "Signed-off-by" over "Signed-Off-By" and "Acked-by:" over "Acked-By".</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 diff</code> or | |
| <code>git format-patch</code>, if your patch involves file renames. The | |
| receiving end can handle them just fine.</p></div> | |
| <div class="paragraph" id="review-patch"><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"> | |
| <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"> | |
| <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<span class="footnote" id="_footnote_security-ml"><br />[The Git Security mailing list: <a href="mailto:git-security@googlegroups.com">git-security@googlegroups.com</a>]<br /></span>, 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><span class="footnote" id="_footnote_contrib-scripts"><br />[Scripts under <code>contrib/</code> are not part of the core <code>git</code> binary and must be called directly. Clone the Git codebase and run <code>perl contrib/contacts/git-contacts</code>.]<br /></span> 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><code> git send-email --cc-cmd='perl contrib/contacts/git-contacts' feature/*.patch</code></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<span class="footnote"><br />[The current maintainer: <a href="mailto:gitster@pobox.com">gitster@pobox.com</a>]<br /></span> | |
| and "cc:" the list<span class="footnote"><br />[The mailing list: <a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>]<br /></span> 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> lines as necessary to credit people who helped your | |
| patch, and "cc:" them when sending such a final version for inclusion.</p></div> | |
| </div> | |
| <div class="sect3"> | |
| <h4 id="_code_format_patch_code_and_code_send_email_code"><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"> | |
| <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 to send in your | |
| patches (see <a href="MyFirstContribution.html">MyFirstContribution</a>).</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.</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"> | |
| <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 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 format-patch --subject-prefix=<text></code>. As a shortcut, you | |
| can use <code>--rfc</code> instead of <code>--subject-prefix="RFC PATCH"</code>, or | |
| <code>-v <n></code> instead of <code>--subject-prefix="PATCH v<n>"</code>.</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 format-patch --notes</code>.</p></div> | |
| <div class="paragraph" id="the-topic-summary"><p><strong>This is EXPERIMENTAL</strong>.</p></div> | |
| <div class="paragraph"><p>When sending a topic, you can propose 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 paragraph of the cover letter. For a single-patch | |
| series, use the space between the three-dash line and the diffstat, as | |
| described earlier.</p></div> | |
| <div class="paragraph" id="attachment"><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 class="paragraph" id="pgp-signature"><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 PGP SIGNED 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><code>$ mine='kn/ref-transaction-symref' | |
| $ git checkout "origin/seen^{/^Merge branch '$mine'}...master"</code></pre> | |
| </div></div> | |
| </li> | |
| <li> | |
| <p> | |
| Apply your format-patch result. There are two cases | |
| </p> | |
| <div class="olist loweralpha"><ol class="loweralpha"> | |
| <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><code>$ 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 ...</code></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><code>$ git format-patch "HEAD^{/^Merge branch 'ba/zqux'}"..HEAD</code></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><code>$ git checkout --detach 'origin/seen' | |
| $ git revert -m 1 <the merge of the previous iteration into seen> | |
| $ git merge kn/ref-transaction-symref</code></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><code>$ git checkout --detach 'origin/next' | |
| $ git merge kn/ref-transaction-symref</code></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 git-gui project, maintained by Johannes Sixt: | |
| </p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code>https://github.com/j6t/git-gui</code></pre> | |
| </div></div> | |
| </li> | |
| <li> | |
| <p> | |
| <code>gitk-git/</code> comes from Paul Mackerras’s gitk project: | |
| </p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code>git://git.ozlabs.org/~paulus/gitk</code></pre> | |
| </div></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code>Those who are interested in improving gitk can volunteer to help Paul | |
| maintain it, cf. <YntxL/fTplFm8lr6@cleo>.</code></pre> | |
| </div></div> | |
| </li> | |
| <li> | |
| <p> | |
| <code>po/</code> comes from the localization coordinator, Jiang Xin: | |
| </p> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code>https://github.com/git-l10n/git-po/</code></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><code>https://github.com/jnavila/git-manpages-l10n/</code></pre> | |
| </div></div> | |
| </li> | |
| </ul></div> | |
| </div> | |
| </div> | |
| <div class="sect1"> | |
| <h2 id="_github_ci_a_id_ghci_a">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">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">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/">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/<Your GitHub handle>/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> | |
| </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><code>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.</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>(Linus Torvalds)</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code>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;</code></pre> | |
| </div></div> | |
| <div class="paragraph"><p>(Daniel Barkalow)</p></div> | |
| <div class="literalblock"> | |
| <div class="content"> | |
| <pre><code>> 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.</code></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 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> | |
| <div id="footer"> | |
| <div id="footer-text"> | |
| Last updated | |
| 2024-07-12 09:18:17 PDT | |
| </div> | |
| </div> | |
| </body> | |
| </html> |