diff options
| author | Junio C Hamano <gitster@pobox.com> | 2022-09-21 15:47:52 -0700 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2022-09-21 15:47:52 -0700 |
| commit | a1ee129f6273b4bebf20726604a5f9eeb873ffa9 (patch) | |
| tree | 924dc36d5040f88b1d3797c823686e35e290926b | |
| parent | bb778e77f3ba317e02d2880ca7148ea66a17dd8a (diff) | |
| download | git-htmldocs-a1ee129f6273b4bebf20726604a5f9eeb873ffa9.tar.gz | |
Autogenerated HTML docs for v2.38.0-rc1
43 files changed, 1231 insertions, 60 deletions
diff --git a/MyFirstContribution.html b/MyFirstContribution.html index 5b18b97a1..1d0668361 100644 --- a/MyFirstContribution.html +++ b/MyFirstContribution.html @@ -1880,7 +1880,7 @@ as version "2". For instance, you may notice that your v2 patches are all named like <code>v2-000n-my-commit-subject.patch</code>. <code>-v2</code> will also format
your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]",
and your range-diff will be prefaced with "Range-diff against v1".</p></div>
-<div class="paragraph"><p>Afer you run this command, <code>format-patch</code> will output the patches to the <code>psuh/</code>
+<div class="paragraph"><p>After you run this command, <code>format-patch</code> will output the patches to the <code>psuh/</code>
directory, alongside the v1 patches. Using a single directory makes it easy to
refer to the old v1 patches while proofreading the v2 patches, but you will need
to be careful to send out only the v2 patches. We will use a pattern like
@@ -2060,7 +2060,7 @@ should generate your diffs from <code><topic>..<mybranch></code> and <div id="footer">
<div id="footer-text">
Last updated
- 2022-05-25 17:44:40 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
diff --git a/MyFirstContribution.txt b/MyFirstContribution.txt index 1da15d9ad..1a4be8ee0 100644 --- a/MyFirstContribution.txt +++ b/MyFirstContribution.txt @@ -1160,7 +1160,7 @@ all named like `v2-000n-my-commit-subject.patch`. `-v2` will also format your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]", and your range-diff will be prefaced with "Range-diff against v1". -Afer you run this command, `format-patch` will output the patches to the `psuh/` +After you run this command, `format-patch` will output the patches to the `psuh/` directory, alongside the v1 patches. Using a single directory makes it easy to refer to the old v1 patches while proofreading the v2 patches, but you will need to be careful to send out only the v2 patches. We will use a pattern like diff --git a/MyFirstObjectWalk.html b/MyFirstObjectWalk.html index c229a33b3..47f8daadb 100644 --- a/MyFirstObjectWalk.html +++ b/MyFirstObjectWalk.html @@ -1343,7 +1343,7 @@ the arguments to <code>traverse_commit_list()</code>.</p></div> </p>
</li>
</ul></div>
-<div class="paragraph"><p>In addition, <code>traverse_commit_list_filtered()</code> has an additional paramter:</p></div>
+<div class="paragraph"><p>In addition, <code>traverse_commit_list_filtered()</code> has an additional parameter:</p></div>
<div class="ulist"><ul>
<li>
<p>
@@ -1722,7 +1722,7 @@ Changed the display order of the filtered object walk <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-27 10:29:17 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
diff --git a/MyFirstObjectWalk.txt b/MyFirstObjectWalk.txt index 8d9e85566..eee513e86 100644 --- a/MyFirstObjectWalk.txt +++ b/MyFirstObjectWalk.txt @@ -534,7 +534,7 @@ the arguments to `traverse_commit_list()`. - `void *show_data`: A context buffer which is passed in turn to `show_commit` and `show_object`. -In addition, `traverse_commit_list_filtered()` has an additional paramter: +In addition, `traverse_commit_list_filtered()` has an additional parameter: - `struct oidset *omitted`: A linked-list of object IDs which the provided filter caused to be omitted. diff --git a/RelNotes/2.38.0.txt b/RelNotes/2.38.0.txt index 5d9bd8c29..870581fc5 100644 --- a/RelNotes/2.38.0.txt +++ b/RelNotes/2.38.0.txt @@ -390,6 +390,14 @@ Fixes since v2.37 been corrected. (merge 49ca2fba39 jk/proto-v2-ref-prefix-fix later to maint). + * A result from opendir() was leaking in the commit-graph expiration + codepath, which has been plugged. + (merge 12f1ae5324 ml/commit-graph-expire-dir-leak-fix later to maint). + + * Just like we have coding guidelines, we now have guidelines for + reviewers. + (merge e01b851923 vd/doc-reviewing-guidelines later to maint). + * Other code cleanup, docfix, build fix, etc. (merge 77b9e85c0f vd/fix-perf-tests later to maint). (merge 0682bc43f5 jk/test-crontab-fixes later to maint). diff --git a/ReviewingGuidelines.html b/ReviewingGuidelines.html new file mode 100644 index 000000000..cb827fdd7 --- /dev/null +++ b/ReviewingGuidelines.html @@ -0,0 +1,981 @@ +<?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>Reviewing Patches in the Git Project</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>Reviewing Patches in the Git Project</h1>
+</div>
+<div id="content">
+<div class="sect1">
+<h2 id="_introduction">Introduction</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.</p></div>
+<div class="paragraph"><p>Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_principles">Principles</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_selecting_patch_es_to_review">Selecting patch(es) to review</h3>
+<div class="paragraph"><p>If you are looking for a patch series in need of review, start by checking
+latest "What’s cooking in git.git" email
+(<a href="https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/">example</a>). The "What’s
+cooking" emails & replies can be found using the query <code>s:"What's cooking"</code> on
+the <a href="https://lore.kernel.org/git/"><code>lore.kernel.org</code> mailing list archive</a>;
+alternatively, you can find the contents of the "What’s cooking" email tracked
+in <code>whats-cooking.txt</code> on the <code>todo</code> branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.</p></div>
+<div class="paragraph"><p>Patches can also be searched manually in the mailing list archive using a query
+like <code>s:"PATCH" -s:"Re:"</code>. You can browse these results for topics relevant to
+your expertise or interest.</p></div>
+<div class="paragraph"><p>If you’ve already contributed to Git, you may also be CC’d in another
+contributor’s patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn’t work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.</p></div>
+</div>
+<div class="sect2">
+<h3 id="_reviewing_patches">Reviewing patches</h3>
+<div class="paragraph"><p>While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.</p></div>
+<div class="sect3">
+<h4 id="_high_level_guidance">High-level guidance</h4>
+<div class="ulist"><ul>
+<li>
+<p>
+Remember to review the content of commit messages for correctness and clarity,
+ in addition to the code change in the patch’s diff. The commit message of a
+ patch should accurately and fully explain the code change being made in the
+ diff.
+</p>
+</li>
+<li>
+<p>
+Reviewing test coverage is an important - but easy to overlook - component of
+ reviews. A patch’s changes may be covered by existing tests, or new tests may
+ be introduced to exercise new behavior. Checking out a patch or series locally
+ allows you to manually mutate lines of new & existing tests to verify expected
+ pass/fail behavior. You can use this information to verify proper coverage or
+ to suggest additional tests the author could add.
+</p>
+</li>
+<li>
+<p>
+When providing a recommendation, be as clear as possible about whether you
+ consider it "blocking" (the code would be broken or otherwise made worse if an
+ issue isn’t fixed) or "non-blocking" (the patch could be made better by taking
+ the recommendation, but acceptance of the series does not require it).
+ Non-blocking recommendations can be particularly ambiguous when they are
+ related to - but outside the scope of - a series ("nice-to-have"s), or when
+ they represent only stylistic differences between the author and reviewer.
+</p>
+</li>
+<li>
+<p>
+When commenting on an issue, try to include suggestions for how the author
+ could fix it. This not only helps the author to understand and fix the issue,
+ it also deepens and improves your understanding of the topic.
+</p>
+</li>
+<li>
+<p>
+Reviews do not need to exclusively point out problems. Feel free to "think out
+ loud" in your review: describe how you read & understood a complex section of
+ a patch, ask a question about something that confused you, point out something
+ you found exceptionally well-written, etc. In particular, uplifting feedback
+ goes a long way towards encouraging contributors to participate more actively
+ in the Git community.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect3">
+<h4 id="_performing_your_review">Performing your review</h4>
+<div class="ulist"><ul>
+<li>
+<p>
+Provide your review comments per-patch in a plaintext "Reply-All" email to the
+ relevant patch. Comments should be made inline, immediately below the relevant
+ section(s).
+</p>
+</li>
+<li>
+<p>
+You may find that the limited context provided in the patch diff is sometimes
+ insufficient for a thorough review. In such cases, you can review patches in
+ your local tree by either applying patches with <a href="git-am.html">git-am(1)</a> or checking
+ out the associated branch from <a href="https://github.com/gitster/git">https://github.com/gitster/git</a> once the series
+ is tracked there.
+</p>
+</li>
+<li>
+<p>
+Large, complicated patch diffs are sometimes unavoidable, such as when they
+ refactor existing code. If you find such a patch difficult to parse, try
+ reviewing the diff produced with the <code>--color-moved</code> and/or
+ <code>--ignore-space-change</code> options.
+</p>
+</li>
+<li>
+<p>
+If a patch is long, you are encouraged to delete parts of it that are
+ unrelated to your review from the email reply. Make sure to leave enough
+ context for readers to understand your comments!
+</p>
+</li>
+<li>
+<p>
+If you cannot complete a full review of a series all at once, consider letting
+ the author know (on- or off-list) if/when you plan to review the rest of the
+ series.
+</p>
+</li>
+</ul></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_completing_a_review">Completing a review</h3>
+<div class="paragraph"><p>Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).</p></div>
+<div class="paragraph"><p>After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version’s cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.</p></div>
+<div class="paragraph"><p>Finally, subsequent "What’s cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the ‘next` branch (typically phrased
+"Will merge to 'next’?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).</p></div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_terminology">Terminology</h2>
+<div class="sectionbody">
+<div class="dlist"><dl>
+<dt class="hdlist1">
+nit:
+</dt>
+<dd>
+<p>
+ Denotes a small issue that should be fixed, such as a typographical error
+ or mis-alignment of conditions in an <code>if()</code> statement.
+</p>
+</dd>
+<dt class="hdlist1">
+aside:
+</dt>
+<dt class="hdlist1">
+optional:
+</dt>
+<dt class="hdlist1">
+non-blocking:
+</dt>
+<dd>
+<p>
+ Indicates to the reader that the following comment should not block the
+ acceptance of the patch or series. These are typically recommendations
+ related to code organization & style, or musings about topics related to
+ the patch in question, but beyond its scope.
+</p>
+</dd>
+<dt class="hdlist1">
+s/<before>/<after>/
+</dt>
+<dd>
+<p>
+ Shorthand for "you wrote <before>, but I think you meant <after>," usually
+ for misspellings or other typographical errors. The syntax is a reference
+ to "substitute" command commonly found in Unix tools such as <code>ed</code>, <code>sed</code>,
+ <code>vim</code>, and <code>perl</code>.
+</p>
+</dd>
+<dt class="hdlist1">
+cover letter
+</dt>
+<dd>
+<p>
+ The "Patch 0" of a multi-patch series. This email describes the
+ high-level intent and structure of the patch series to readers on the
+ Git mailing list. It is also where the changelog notes and range-diff of
+ subsequent versions are provided by the author.
+</p>
+<div class="paragraph"><p>On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch’s commit
+message (after the <code>---</code>) and the beginning of the diff.</p></div>
+</dd>
+<dt class="hdlist1">
+#leftoverbits
+</dt>
+<dd>
+<p>
+ Used by either an author or a reviewer to describe features or suggested
+ changes that are out-of-scope of a given patch or series, but are relevant
+ to the topic for the sake of discussion.
+</p>
+</dd>
+</dl></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_see_also">See Also</h2>
+<div class="sectionbody">
+<div class="paragraph"><p><a href="MyFirstContribution.html">MyFirstContribution</a></p></div>
+</div>
+</div>
+</div>
+<div id="footnotes"><hr /></div>
+<div id="footer">
+<div id="footer-text">
+Last updated
+ 2022-09-21 15:44:34 PDT
+</div>
+</div>
+</body>
+</html>
diff --git a/ReviewingGuidelines.txt b/ReviewingGuidelines.txt new file mode 100644 index 000000000..0e323d547 --- /dev/null +++ b/ReviewingGuidelines.txt @@ -0,0 +1,162 @@ +Reviewing Patches in the Git Project +==================================== + +Introduction +------------ +The Git development community is a widely distributed, diverse, ever-changing +group of individuals. Asynchronous communication via the Git mailing list poses +unique challenges when reviewing or discussing patches. This document contains +some guiding principles and helpful tools you can use to make your reviews both +more efficient for yourself and more effective for other contributors. + +Note that none of the recommendations here are binding or in any way a +requirement of participation in the Git community. They are provided as a +resource to supplement your skills as a contributor. + +Principles +---------- + +Selecting patch(es) to review +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +If you are looking for a patch series in need of review, start by checking +latest "What's cooking in git.git" email +(https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/[example]). The "What's +cooking" emails & replies can be found using the query `s:"What's cooking"` on +the https://lore.kernel.org/git/[`lore.kernel.org` mailing list archive]; +alternatively, you can find the contents of the "What's cooking" email tracked +in `whats-cooking.txt` on the `todo` branch of Git. Topics tagged with "Needs +review" and those in the "[New Topics]" section are typically those that would +benefit the most from additional review. + +Patches can also be searched manually in the mailing list archive using a query +like `s:"PATCH" -s:"Re:"`. You can browse these results for topics relevant to +your expertise or interest. + +If you've already contributed to Git, you may also be CC'd in another +contributor's patch series. These are topics where the author feels that your +attention is warranted. This may be because their patch changes something you +wrote previously (making you a good judge of whether the new approach does or +doesn't work), or because you have the expertise to provide an exceptionally +helpful review. There is no requirement to review these patches but, in the +spirit of open source collaboration, you should strongly consider doing so. + +Reviewing patches +~~~~~~~~~~~~~~~~~ +While every contributor takes their own approach to reviewing patches, here are +some general pieces of advice to make your reviews as clear and helpful as +possible. The advice is broken into two rough categories: high-level reviewing +guidance, and concrete tips for interacting with patches on the mailing list. + +==== High-level guidance +- Remember to review the content of commit messages for correctness and clarity, + in addition to the code change in the patch's diff. The commit message of a + patch should accurately and fully explain the code change being made in the + diff. + +- Reviewing test coverage is an important - but easy to overlook - component of + reviews. A patch's changes may be covered by existing tests, or new tests may + be introduced to exercise new behavior. Checking out a patch or series locally + allows you to manually mutate lines of new & existing tests to verify expected + pass/fail behavior. You can use this information to verify proper coverage or + to suggest additional tests the author could add. + +- When providing a recommendation, be as clear as possible about whether you + consider it "blocking" (the code would be broken or otherwise made worse if an + issue isn't fixed) or "non-blocking" (the patch could be made better by taking + the recommendation, but acceptance of the series does not require it). + Non-blocking recommendations can be particularly ambiguous when they are + related to - but outside the scope of - a series ("nice-to-have"s), or when + they represent only stylistic differences between the author and reviewer. + +- When commenting on an issue, try to include suggestions for how the author + could fix it. This not only helps the author to understand and fix the issue, + it also deepens and improves your understanding of the topic. + +- Reviews do not need to exclusively point out problems. Feel free to "think out + loud" in your review: describe how you read & understood a complex section of + a patch, ask a question about something that confused you, point out something + you found exceptionally well-written, etc. In particular, uplifting feedback + goes a long way towards encouraging contributors to participate more actively + in the Git community. + +==== Performing your review +- Provide your review comments per-patch in a plaintext "Reply-All" email to the + relevant patch. Comments should be made inline, immediately below the relevant + section(s). + +- You may find that the limited context provided in the patch diff is sometimes + insufficient for a thorough review. In such cases, you can review patches in + your local tree by either applying patches with linkgit:git-am[1] or checking + out the associated branch from https://github.com/gitster/git once the series + is tracked there. + +- Large, complicated patch diffs are sometimes unavoidable, such as when they + refactor existing code. If you find such a patch difficult to parse, try + reviewing the diff produced with the `--color-moved` and/or + `--ignore-space-change` options. + +- If a patch is long, you are encouraged to delete parts of it that are + unrelated to your review from the email reply. Make sure to leave enough + context for readers to understand your comments! + +- If you cannot complete a full review of a series all at once, consider letting + the author know (on- or off-list) if/when you plan to review the rest of the + series. + +Completing a review +~~~~~~~~~~~~~~~~~~~ +Once each patch of a series is reviewed, the author (and/or other contributors) +may discuss the review(s). This may result in no changes being applied, or the +author will send a new version of their patch(es). + +After a series is rerolled in response to your or others' review, make sure to +re-review the updates. If you are happy with the state of the patch series, +explicitly indicate your approval (typically with a reply to the latest +version's cover letter). Optionally, you can let the author know that they can +add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim +in a later iteration of the series. + +Finally, subsequent "What's cooking" emails may explicitly ask whether a +reviewed topic is ready for merging to the `next` branch (typically phrased +"Will merge to \'next\'?"). You can help the maintainer and author by responding +with a short description of the state of your (and others', if applicable) +review, including the links to the relevant thread(s). + +Terminology +----------- +nit: :: + Denotes a small issue that should be fixed, such as a typographical error + or mis-alignment of conditions in an `if()` statement. + +aside: :: +optional: :: +non-blocking: :: + Indicates to the reader that the following comment should not block the + acceptance of the patch or series. These are typically recommendations + related to code organization & style, or musings about topics related to + the patch in question, but beyond its scope. + +s/<before>/<after>/:: + Shorthand for "you wrote <before>, but I think you meant <after>," usually + for misspellings or other typographical errors. The syntax is a reference + to "substitute" command commonly found in Unix tools such as `ed`, `sed`, + `vim`, and `perl`. + +cover letter:: + The "Patch 0" of a multi-patch series. This email describes the + high-level intent and structure of the patch series to readers on the + Git mailing list. It is also where the changelog notes and range-diff of + subsequent versions are provided by the author. ++ +On single-patch submissions, cover letter content is typically not sent as a +separate email. Instead, it is inserted between the end of the patch's commit +message (after the `---`) and the beginning of the diff. + +#leftoverbits:: + Used by either an author or a reviewer to describe features or suggested + changes that are out-of-scope of a given patch or series, but are relevant + to the topic for the sake of discussion. + +See Also +-------- +link:MyFirstContribution.html[MyFirstContribution] diff --git a/SubmittingPatches.html b/SubmittingPatches.html index 6398f30b3..4ee02ac80 100644 --- a/SubmittingPatches.html +++ b/SubmittingPatches.html @@ -1444,7 +1444,7 @@ this problem around.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-15 16:31:12 PDT
+ 2022-09-21 15:44:47 PDT
</div>
</div>
</body>
diff --git a/cmds-ancillaryinterrogators.txt b/cmds-ancillaryinterrogators.txt index d43f7cec9..6248bccbd 100644 --- a/cmds-ancillaryinterrogators.txt +++ b/cmds-ancillaryinterrogators.txt @@ -10,6 +10,9 @@ linkgit:git-bugreport[git]:: linkgit:git-count-objects[git]:: Count unpacked number of objects and their disk consumption. +linkgit:git-diagnose[git]:: + Generate a zip archive of diagnostic information. + linkgit:git-difftool[git]:: Show changes using common diff tools. @@ -37,6 +40,9 @@ linkgit:git-verify-commit[git]:: linkgit:git-verify-tag[git]:: Check the GPG signature of tags. +linkgit:git-version[git]:: + Display version information about Git. + linkgit:git-whatchanged[git]:: Show logs with difference each commit introduces. @@ -1578,6 +1578,14 @@ ancillary user utilities.</p></div> </p>
</dd>
<dt class="hdlist1">
+<a href="git-diagnose.html">git-diagnose(git)</a>
+</dt>
+<dd>
+<p>
+ Generate a zip archive of diagnostic information.
+</p>
+</dd>
+<dt class="hdlist1">
<a href="git-difftool.html">git-difftool(git)</a>
</dt>
<dd>
@@ -1650,6 +1658,14 @@ ancillary user utilities.</p></div> </p>
</dd>
<dt class="hdlist1">
+<a href="git-version.html">git-version(git)</a>
+</dt>
+<dd>
+<p>
+ Display version information about Git.
+</p>
+</dd>
+<dt class="hdlist1">
<a href="git-whatchanged.html">git-whatchanged(git)</a>
</dt>
<dd>
@@ -2504,7 +2520,7 @@ users typically do not use them directly.</p></div> <div class="sectionbody">
<div class="paragraph"><p>This documentation discusses repository and command interfaces which
users are expected to interact with directly. See <code>--user-formats</code> in
-<a href="git-help.html">git-help(1)</a> for more details on the critera.</p></div>
+<a href="git-help.html">git-help(1)</a> for more details on the criteria.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
<a href="gitattributes.html">gitattributes(git)</a>
@@ -3776,7 +3792,7 @@ the Git Security mailing list <<a href="mailto:git-security@googlegroups.com" <div id="footer">
<div id="footer-text">
Last updated
- 2022-08-18 14:11:07 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
@@ -344,7 +344,7 @@ Repository, command and file interfaces This documentation discusses repository and command interfaces which users are expected to interact with directly. See `--user-formats` in -linkgit:git-help[1] for more details on the critera. +linkgit:git-help[1] for more details on the criteria. include::cmds-userinterfaces.txt[] diff --git a/gitprotocol-capabilities.html b/gitprotocol-capabilities.html index 925a43b77..e653f9321 100644 --- a/gitprotocol-capabilities.html +++ b/gitprotocol-capabilities.html @@ -1139,8 +1139,8 @@ the server as well.</p></div> <div class="paragraph"><p>Session IDs should be unique to a given process. They must fit within a
packet-line, and must not contain non-printable or whitespace characters. The
current implementation uses trace2 session IDs (see
-<a href="api-trace2.html">api-trace2</a> for details), but this may change and users of
-the session ID should not rely on this fact.</p></div>
+<a href="technical/api-trace2.html">api-trace2</a> for details), but this may change
+and users of the session ID should not rely on this fact.</p></div>
</div>
</div>
<div class="sect1">
@@ -1154,7 +1154,7 @@ the session ID should not rely on this fact.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-08-18 14:11:07 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
diff --git a/gitprotocol-capabilities.txt b/gitprotocol-capabilities.txt index c6dcc7d56..0fb5ea0c1 100644 --- a/gitprotocol-capabilities.txt +++ b/gitprotocol-capabilities.txt @@ -388,8 +388,8 @@ the server as well. Session IDs should be unique to a given process. They must fit within a packet-line, and must not contain non-printable or whitespace characters. The current implementation uses trace2 session IDs (see -link:api-trace2.html[api-trace2] for details), but this may change and users of -the session ID should not rely on this fact. +link:technical/api-trace2.html[api-trace2] for details), but this may change +and users of the session ID should not rely on this fact. GIT --- diff --git a/gitprotocol-v2.html b/gitprotocol-v2.html index ffd59e1ca..11ed3aa23 100644 --- a/gitprotocol-v2.html +++ b/gitprotocol-v2.html @@ -1439,8 +1439,8 @@ the server as well.</p></div> <div class="paragraph"><p>Session IDs should be unique to a given process. They must fit within a
packet-line, and must not contain non-printable or whitespace characters. The
current implementation uses trace2 session IDs (see
-<a href="api-trace2.html">api-trace2</a> for details), but this may change and users of
-the session ID should not rely on this fact.</p></div>
+<a href="technical/api-trace2.html">api-trace2</a> for details), but this may change
+and users of the session ID should not rely on this fact.</p></div>
</div>
<div class="sect2">
<h3 id="_object_info">object-info</h3>
@@ -1497,7 +1497,7 @@ and associated requested information, each separated by a single space.</p></div <div id="footer">
<div id="footer-text">
Last updated
- 2022-08-18 14:11:07 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
diff --git a/gitprotocol-v2.txt b/gitprotocol-v2.txt index c9c0f9160..59bf41cef 100644 --- a/gitprotocol-v2.txt +++ b/gitprotocol-v2.txt @@ -544,8 +544,8 @@ the server as well. Session IDs should be unique to a given process. They must fit within a packet-line, and must not contain non-printable or whitespace characters. The current implementation uses trace2 session IDs (see -link:api-trace2.html[api-trace2] for details), but this may change and users of -the session ID should not rely on this fact. +link:technical/api-trace2.html[api-trace2] for details), but this may change +and users of the session ID should not rely on this fact. object-info ~~~~~~~~~~~ diff --git a/howto-index.html b/howto-index.html index 8fbe527a5..8fc909e15 100644 --- a/howto-index.html +++ b/howto-index.html @@ -894,7 +894,7 @@ later validate it.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-15 16:31:08 PDT
+ 2022-09-21 15:44:38 PDT
</div>
</div>
</body>
diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html index 3c34fae83..a2f057d29 100644 --- a/howto/coordinate-embargoed-releases.html +++ b/howto/coordinate-embargoed-releases.html @@ -873,7 +873,7 @@ Thanks, <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:18 PDT
+ 2022-09-21 15:44:44 PDT
</div>
</div>
</body>
diff --git a/howto/keep-canonical-history-correct.html b/howto/keep-canonical-history-correct.html index 7eceec6c8..88677b957 100644 --- a/howto/keep-canonical-history-correct.html +++ b/howto/keep-canonical-history-correct.html @@ -938,7 +938,7 @@ tip of your <em>master</em> again and redo the two merges:</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:18 PDT
+ 2022-09-21 15:44:44 PDT
</div>
</div>
</body>
diff --git a/howto/maintain-git.html b/howto/maintain-git.html index 27c48d24d..e9d2f163a 100644 --- a/howto/maintain-git.html +++ b/howto/maintain-git.html @@ -1469,7 +1469,7 @@ $ git update-ref -d $mf/ai/topic</code></pre> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:18 PDT
+ 2022-09-21 15:44:44 PDT
</div>
</div>
</body>
diff --git a/howto/new-command.html b/howto/new-command.html index f39ac75b4..7b0db7a16 100644 --- a/howto/new-command.html +++ b/howto/new-command.html @@ -863,7 +863,7 @@ letter [PATCH 0/n]. <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:15 PDT
+ 2022-09-21 15:44:40 PDT
</div>
</div>
</body>
diff --git a/howto/rebase-from-internal-branch.html b/howto/rebase-from-internal-branch.html index 09ac6723e..9f19c8773 100644 --- a/howto/rebase-from-internal-branch.html +++ b/howto/rebase-from-internal-branch.html @@ -895,7 +895,7 @@ the #1' commit.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:18 PDT
+ 2022-09-21 15:44:44 PDT
</div>
</div>
</body>
diff --git a/howto/rebuild-from-update-hook.html b/howto/rebuild-from-update-hook.html index fb1bbd1da..c5834413f 100644 --- a/howto/rebuild-from-update-hook.html +++ b/howto/rebuild-from-update-hook.html @@ -847,7 +847,7 @@ This is still crude and does not protect against simultaneous <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:17 PDT
+ 2022-09-21 15:44:43 PDT
</div>
</div>
</body>
diff --git a/howto/recover-corrupted-blob-object.html b/howto/recover-corrupted-blob-object.html index eddc3d8c6..464884192 100644 --- a/howto/recover-corrupted-blob-object.html +++ b/howto/recover-corrupted-blob-object.html @@ -880,7 +880,7 @@ thing.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:17 PDT
+ 2022-09-21 15:44:43 PDT
</div>
</div>
</body>
diff --git a/howto/recover-corrupted-object-harder.html b/howto/recover-corrupted-object-harder.html index 4ef81ee1f..a3468c483 100644 --- a/howto/recover-corrupted-object-harder.html +++ b/howto/recover-corrupted-object-harder.html @@ -1189,7 +1189,7 @@ int main(int argc, char **argv) <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:17 PDT
+ 2022-09-21 15:44:43 PDT
</div>
</div>
</body>
diff --git a/howto/revert-a-faulty-merge.html b/howto/revert-a-faulty-merge.html index aea3f13d0..69b6c569b 100644 --- a/howto/revert-a-faulty-merge.html +++ b/howto/revert-a-faulty-merge.html @@ -1025,7 +1025,7 @@ P---o---o---M---x---x---W---x---M2 <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:17 PDT
+ 2022-09-21 15:44:43 PDT
</div>
</div>
</body>
diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index 3720f1e7c..452f6e292 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html @@ -907,7 +907,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:16 PDT
+ 2022-09-21 15:44:40 PDT
</div>
</div>
</body>
diff --git a/howto/separating-topic-branches.html b/howto/separating-topic-branches.html index 3d3fd1bb3..ce86293c1 100644 --- a/howto/separating-topic-branches.html +++ b/howto/separating-topic-branches.html @@ -841,7 +841,7 @@ o---o"master"</code></pre> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:17 PDT
+ 2022-09-21 15:44:42 PDT
</div>
</div>
</body>
diff --git a/howto/setup-git-server-over-http.html b/howto/setup-git-server-over-http.html index b9e6e3574..2d27571a3 100644 --- a/howto/setup-git-server-over-http.html +++ b/howto/setup-git-server-over-http.html @@ -1071,7 +1071,7 @@ help diagnosing the problem, but removes security checks.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:17 PDT
+ 2022-09-21 15:44:42 PDT
</div>
</div>
</body>
diff --git a/howto/update-hook-example.html b/howto/update-hook-example.html index 8a2bbc2b7..6dc53d134 100644 --- a/howto/update-hook-example.html +++ b/howto/update-hook-example.html @@ -930,7 +930,7 @@ that JC can make non-fast-forward pushes on it.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:16 PDT
+ 2022-09-21 15:44:42 PDT
</div>
</div>
</body>
diff --git a/howto/use-git-daemon.html b/howto/use-git-daemon.html index c9de227ee..5d9402f26 100644 --- a/howto/use-git-daemon.html +++ b/howto/use-git-daemon.html @@ -791,7 +791,7 @@ a good practice to put the paths after a "--" separator.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:16 PDT
+ 2022-09-21 15:44:41 PDT
</div>
</div>
</body>
diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index 7ebc5e8f0..b7827f5ea 100644 --- a/howto/using-merge-subtree.html +++ b/howto/using-merge-subtree.html @@ -848,7 +848,7 @@ Please note that if the other project merges from you, then it will <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:16 PDT
+ 2022-09-21 15:44:40 PDT
</div>
</div>
</body>
diff --git a/howto/using-signed-tag-in-pull-request.html b/howto/using-signed-tag-in-pull-request.html index 3f0b7eeaa..fa88d07f4 100644 --- a/howto/using-signed-tag-in-pull-request.html +++ b/howto/using-signed-tag-in-pull-request.html @@ -952,7 +952,7 @@ as part of the merge commit.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-19 15:04:16 PDT
+ 2022-09-21 15:44:41 PDT
</div>
</div>
</body>
diff --git a/technical/api-error-handling.html b/technical/api-error-handling.html index c9659fcb7..70dbbf693 100644 --- a/technical/api-error-handling.html +++ b/technical/api-error-handling.html @@ -799,7 +799,7 @@ parse-options.c.</p></div> </li>
</ul></div>
<div class="paragraph"><p>These reports will be logged via the trace2 facility. See the "error"
-event in <a href="api-trace2.txt">trace2 API</a>.</p></div>
+event in <a href="api-trace2.html">trace2 API</a>.</p></div>
</div>
</div>
<div class="sect1">
@@ -878,7 +878,7 @@ a message, pass a strbuf that is explicitly ignored:</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-06-10 15:52:52 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
diff --git a/technical/api-error-handling.txt b/technical/api-error-handling.txt index 70bf1d3e5..665c4960b 100644 --- a/technical/api-error-handling.txt +++ b/technical/api-error-handling.txt @@ -46,7 +46,7 @@ parse-options.c. returns -1 after reporting the situation to the caller. These reports will be logged via the trace2 facility. See the "error" -event in link:api-trace2.txt[trace2 API]. +event in link:api-trace2.html[trace2 API]. Customizable error handlers --------------------------- diff --git a/technical/api-index.html b/technical/api-index.html index bb337b5ab..32213dff0 100644 --- a/technical/api-index.html +++ b/technical/api-index.html @@ -775,7 +775,7 @@ documents them.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-15 16:31:14 PDT
+ 2022-09-21 15:44:50 PDT
</div>
</div>
</body>
diff --git a/technical/api-parse-options.html b/technical/api-parse-options.html index 8820a402d..ed4a928a8 100644 --- a/technical/api-parse-options.html +++ b/technical/api-parse-options.html @@ -833,7 +833,7 @@ There must be exactly one subcommand among the arguments, or zero if the <p>
All arguments following the subcommand are considered to be arguments of
the subcommand, and, conversely, arguments meant for the subcommand may
- not preceed the subcommand.
+ not precede the subcommand.
</p>
</li>
</ul></div>
@@ -1351,7 +1351,7 @@ for real-world examples.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-01 13:55:22 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
diff --git a/technical/api-parse-options.txt b/technical/api-parse-options.txt index c2a5e4291..61fa6ee16 100644 --- a/technical/api-parse-options.txt +++ b/technical/api-parse-options.txt @@ -60,7 +60,7 @@ Subcommands are special in a couple of ways: * All arguments following the subcommand are considered to be arguments of the subcommand, and, conversely, arguments meant for the subcommand may - not preceed the subcommand. + not precede the subcommand. Therefore, if the options array contains at least one subcommand and `parse_options()` encounters the first dashless argument, it will either: diff --git a/technical/bundle-uri.html b/technical/bundle-uri.html index 4c392bcf1..f22657a9b 100644 --- a/technical/bundle-uri.html +++ b/technical/bundle-uri.html @@ -741,8 +741,7 @@ asciidoc.install(); <div class="sectionbody">
<div class="paragraph"><p>Git bundles are files that store a pack-file along with some extra metadata,
including a set of refs and a (possibly empty) set of necessary commits. See
-<a href="../git-bundle.html">git-bundle(1)</a> and <a href="bundle-format.txt">the bundle format</a> for more
-information.</p></div>
+<a href="../git-bundle.html">git-bundle(1)</a> and <a href="../gitformat-bundle.html">gitformat-bundle(5)</a> for more information.</p></div>
<div class="paragraph"><p>Bundle URIs are locations where Git can download one or more bundles in
order to bootstrap the object database in advance of fetching the remaining
objects from a remote.</p></div>
@@ -1118,7 +1117,7 @@ bundle list (although we do <em>not</em> want to use parallel downloads here). W expect that the process will end when all prerequisite commit OIDs in a
thin bundle are already in the object database.</p></div>
<div class="paragraph"><p>When using the <code>creationToken</code> heuristic, the client can avoid downloading
-any bundles if their creation tokenss are not larger than the stored
+any bundles if their creation tokens are not larger than the stored
creation token. After fetching new bundles, Git updates this local
creation token.</p></div>
<div class="paragraph"><p>If the bundle provider does not provide a heuristic, then the client
@@ -1154,7 +1153,7 @@ The client receives a 400-level response (such as <code>404 Not Found</code> or </li>
<li>
<p>
-The server reports any other failure reponse.
+The server reports any other failure response.
</p>
</li>
<li>
@@ -1307,7 +1306,7 @@ is to have more frequent bundle creation. For example, bundles could be created every hour, and then once a day those "hourly" bundles could be
merged into a "daily" bundle. The daily bundles are merged into the
oldest bundle after 30 days.</p></div>
-<div class="paragraph"><p>It is recommened that this bundle strategy is repeated with the <code>blob:none</code>
+<div class="paragraph"><p>It is recommended that this bundle strategy is repeated with the <code>blob:none</code>
filter if clients of this repository are expecting to use blobless partial
clones. This list of blobless bundles stays in the same list as the full
bundles, but uses the <code>bundle.<id>.filter</code> key to separate the two groups.
@@ -1464,7 +1463,7 @@ would cause these on-demand downloads to be too aggressive.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-08-18 14:11:07 PDT
+ 2022-09-21 15:44:34 PDT
</div>
</div>
</body>
diff --git a/technical/bundle-uri.txt b/technical/bundle-uri.txt index c25c42378..18f2dedd4 100644 --- a/technical/bundle-uri.txt +++ b/technical/bundle-uri.txt @@ -3,8 +3,7 @@ Bundle URIs Git bundles are files that store a pack-file along with some extra metadata, including a set of refs and a (possibly empty) set of necessary commits. See -linkgit:git-bundle[1] and link:bundle-format.txt[the bundle format] for more -information. +linkgit:git-bundle[1] and linkgit:gitformat-bundle[5] for more information. Bundle URIs are locations where Git can download one or more bundles in order to bootstrap the object database in advance of fetching the remaining @@ -290,7 +289,7 @@ expect that the process will end when all prerequisite commit OIDs in a thin bundle are already in the object database. When using the `creationToken` heuristic, the client can avoid downloading -any bundles if their creation tokenss are not larger than the stored +any bundles if their creation tokens are not larger than the stored creation token. After fetching new bundles, Git updates this local creation token. @@ -319,7 +318,7 @@ Here are a few example error conditions: Git's other HTTP protocols in terms of handling specific 400-level errors. -* The server reports any other failure reponse. +* The server reports any other failure response. * The client receives data that is not parsable as a bundle or bundle list. @@ -447,7 +446,7 @@ created every hour, and then once a day those "hourly" bundles could be merged into a "daily" bundle. The daily bundles are merged into the oldest bundle after 30 days. -It is recommened that this bundle strategy is repeated with the `blob:none` +It is recommended that this bundle strategy is repeated with the `blob:none` filter if clients of this repository are expecting to use blobless partial clones. This list of blobless bundles stays in the same list as the full bundles, but uses the `bundle.<id>.filter` key to separate the two groups. diff --git a/technical/commit-graph.txt b/technical/commit-graph.txt index f05e7bda1..90c9760c2 100644 --- a/technical/commit-graph.txt +++ b/technical/commit-graph.txt @@ -40,7 +40,7 @@ Values 1-4 satisfy the requirements of parse_commit_gently(). There are two definitions of generation number: 1. Corrected committer dates (generation number v2) -2. Topological levels (generation nummber v1) +2. Topological levels (generation number v1) Define "corrected committer date" of a commit recursively as follows: @@ -48,7 +48,7 @@ Define "corrected committer date" of a commit recursively as follows: equal to its committer date. * A commit with at least one parent has corrected committer date equal to - the maximum of its commiter date and one more than the largest corrected + the maximum of its committer date and one more than the largest corrected committer date among its parents. * As a special case, a root commit with timestamp zero has corrected commit diff --git a/technical/remembering-renames.txt b/technical/remembering-renames.txt index af091a755..1e34d9139 100644 --- a/technical/remembering-renames.txt +++ b/technical/remembering-renames.txt @@ -407,7 +407,7 @@ considered to be "irrelevant". See for example the following commits: no longer relevant", 2021-03-13) Relevance is always determined by what the _other_ side of history has -done, in terms of modifing a file that our side renamed, or adding a +done, in terms of modifying a file that our side renamed, or adding a file to a directory which our side renamed. This means that a path that is "irrelevant" when picking the first commit of a series in a rebase or cherry-pick, may suddenly become "relevant" when picking the diff --git a/user-manual.html b/user-manual.html index 0bee55c8a..f29318aad 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1393,7 +1393,7 @@ individual files. The second is the amount of space taken up by those "loose" objects.</p><p>You can save space and make Git faster by moving these loose objects in to a "pack file", which stores a group of objects in an efficient compressed format; the details of how pack files are formatted can be -found in <a class="ulink" href="gitformat-pack" target="_top">5</a>.</p><p>To put the loose objects into a pack, just run git repack:</p><pre class="screen">$ git repack +found in <a class="ulink" href="gitformat-pack.html" target="_top">gitformat-pack(5)</a>.</p><p>To put the loose objects into a pack, just run git repack:</p><pre class="screen">$ git repack Counting objects: 6020, done. Delta compression using up to 4 threads. Compressing objects: 100% (6020/6020), done. diff --git a/user-manual.txt b/user-manual.txt index ca9decdd9..dc9c6a663 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -3133,7 +3133,7 @@ those "loose" objects. You can save space and make Git faster by moving these loose objects in to a "pack file", which stores a group of objects in an efficient compressed format; the details of how pack files are formatted can be -found in link:gitformat-pack[5]. +found in linkgit:gitformat-pack[5]. To put the loose objects into a pack, just run git repack: |