Autogenerated HTML docs for v2.47.0-72-gef8ce8

Author: gitster

DecisionMaking.html

@@ -442,7 +442,7 @@
 <div id="header">
 <h1>Decision-Making Process in the Git Project</h1>
 <div class="details">
-<span id="revdate">2024-10-06</span>
+<span id="revdate">2024-10-10</span>
 </div>
 </div>
 <div id="content">

MyFirstContribution.html

@@ -0,0 +1,35 @@
+Git v2.48 Release Notes
+=======================
+
+UI, Workflows & Features
+------------------------
+
+Performance, Internal Implementation, Development Support etc.
+--------------------------------------------------------------
+
+ * Document "amlog" notes.
+   (merge ddfb5bcfc6 tb/notes-amlog-doc later to maint).
+
+ * The way AsciiDoc is used for SYNOPSIS part of the manual pages has
+   been revamped.  The sources, at least for the simple cases, got
+   vastly pleasant to work with.
+
+ * The reftable library is now prepared to expect that the memory
+   allocation function given to it may fail to allocate and to deal
+   with such an error.
+
+
+Fixes since v2.47
+-----------------
+
+ * Doc update to clarify how periodical maintenance are scheduled,
+   spread across time to avoid thundering hurds.
+   (merge 3d6ab4177d sk/doc-maintenance-schedule later to maint).
+
+ * Use after free and double freeing at the end in "git log -L... -p"
+   had been identified and fixed.
+   (merge fc5589d6c1 ds/line-log-asan-fix later to maint).
+
+ * Other code cleanup, docfix, build fix, etc.
+   (merge 66893a14d0 ps/leakfixes-part-8 later to maint).
+   (merge 1164e270b5 jk/output-prefix-cleanup later to maint).

MyFirstObjectWalk.html

@@ -442,7 +442,7 @@
 <div id="header">
 <h1>Reviewing Patches in the Git Project</h1>
 <div class="details">
-<span id="revdate">2024-10-06</span>
+<span id="revdate">2024-10-10</span>
 </div>
 </div>
 <div id="content">
@@ -472,7 +472,7 @@ <h3 id="_selecting_patches_to_review">Selecting patch(es) to review</h3>
 <p>If you are looking for a patch series in need of review, start by checking
 the latest "What&#8217;s cooking in git.git" email
 (<a href="https://lore.kernel.org/git/[email protected]/">example</a>). The "What&#8217;s
-cooking" emails &amp; replies can be found using the query <code>s:"What's cooking"</code> on
+cooking" emails &amp; replies can be found using the query <code>s:</code>"What's <code>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&#8217;s cooking" email tracked
 in <code>whats-cooking.txt</code> on the <code>todo</code> branch of Git. Topics tagged with "Needs
@@ -481,7 +481,7 @@ <h3 id="_selecting_patches_to_review">Selecting patch(es) to review</h3>
 </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
+like <code>s:</code>"PATCH" <code>-s:</code>"Re:". You can browse these results for topics relevant to
 your expertise or interest.</p>
 </div>
 <div class="paragraph">
@@ -634,7 +634,7 @@ <h2 id="_terminology">Terminology</h2>
 <dt class="hdlist1">nit: </dt>
 <dd>
 <p>Denotes a small issue that should be fixed, such as a typographical error
-or misalignment of conditions in an <code>if()</code> statement.</p>
+or misalignment of conditions in an <code>if</code>() statement.</p>
 </dd>
 <dt class="hdlist1">aside: </dt>
 <dt class="hdlist1">optional: </dt>

RelNotes/2.48.0.txt

@@ -442,7 +442,7 @@
 <div id="header">
 <h1>Submitting Patches</h1>
 <div class="details">
-<span id="revdate">2024-10-06</span>
+<span id="revdate">2024-10-10</span>
 </div>
 </div>
 <div id="content">
@@ -487,7 +487,7 @@ <h3 id="patch-flow">A typical life cycle of a patch series</h3>
 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&#8217;t demand).  <code>git log -p &#x2d;&#x2d; <em>$area_you_are_modifying</em></code> would
+you don&#8217;t demand).  <code>git</code> <code>log</code> <code>-p</code> &#x2d;&#x2d; <code><em>$area_you_are_modifying</em></code> would
 help you find out who they are.</p>
 </div>
 </li>
@@ -574,8 +574,8 @@ <h3 id="choose-starting-point">Choose a starting point.</h3>
 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&#8217;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
+git.git" announcements.  To find the tip of a topic branch, run <code>git</code> <code>log</code>
+<code>--first-parent</code> <code>master</code><code>..</code><code>seen</code> and look for the merge commit. The second
 parent of this commit is the tip of the topic branch.</p>
 </div>
 <div class="paragraph">
@@ -608,7 +608,7 @@ <h3 id="choose-starting-point">Choose a starting point.</h3>
 <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
+than the recent releases.  <code>git</code> <code>describe</code> <code>--contains</code> <code>X</code> may describe
 <code>X</code> as <code>v2.30.0-rc2-gXXXXXX</code> for the commit <code>X</code> that introduced the
 bug, and the bug may be so high-impact that we may need to issue a new
 maintenance release for Git 2.30.x series, when "Git 2.41.0" is the
@@ -730,7 +730,7 @@ <h3 id="separate-commits">Make separate commits for logically separate changes.<
 <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>
+run <code>git</code> <code>diff</code> <code>--check</code> on your changes before you commit.</p>
 </div>
 </div>
 <div class="sect2">
@@ -791,7 +791,7 @@ <h3 id="describe-changes">Describe your changes well.</h3>
 </ul>
 </div>
 <div class="paragraph">
-<p>If in doubt which identifier to use, run <code>git log --no-merges</code> on the
+<p>If in doubt which identifier to use, run <code>git</code> <code>log</code> <code>--no-merges</code> on the
 files you are modifying to see the current conventions.</p>
 </div>
 <div id="summary-section" class="paragraph">
@@ -871,7 +871,7 @@ <h3 id="describe-changes">Describe your changes well.</h3>
 <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>
+invocation of <code>git</code> <code>show</code>:</p>
 </div>
 <div class="literalblock">
 <div class="content">
@@ -1022,8 +1022,8 @@ <h3 id="git-tools">Generate your patch using Git tools out of your commits.</h3>
 <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
+<p>You do not have to be afraid to use <code>-M</code> option to <code>git</code> <code>diff</code> or
+<code>git</code> <code>format-patch</code>, if your patch involves file renames.  The
 receiving end can handle them just fine.</p>
 </div>
 <div id="review-patch" class="paragraph">
@@ -1168,7 +1168,7 @@ <h4 id="_format_patch_and_send_email"><code>format-patch</code> and <code>send-e
 previously sent.</p>
 </div>
 <div class="paragraph">
-<p>The <code>git format-patch</code> command follows the best current practice to
+<p>The <code>git</code> <code>format-patch</code> command follows the best current practice to
 format the body of an e-mail message.  At the beginning of the
 patch should come your commit message, ending with the
 <code>Signed-off-by</code> trailers, and a line that consists of three dashes,
@@ -1177,9 +1177,9 @@ <h4 id="_format_patch_and_send_email"><code>format-patch</code> and <code>send-e
 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 "[&lt;text&gt;]", use
-<code>git format-patch --subject-prefix=&lt;text&gt;</code>.  As a shortcut, you
-can use <code>--rfc</code> instead of <code>--subject-prefix="RFC PATCH"</code>, or
-<code>-v &lt;n&gt;</code> instead of <code>--subject-prefix="PATCH v&lt;n&gt;"</code>.</p>
+<code>git</code> <code>format-patch</code> <code>--subject-prefix=</code><em>&lt;text&gt;</em>.  As a shortcut, you
+can use <code>--rfc</code> instead of <code>--subject-prefix=</code>"RFC <code>PATCH</code>", or
+<code>-v</code> <em>&lt;n&gt;</em> instead of <code>--subject-prefix=</code>"PATCH <code>v</code><em>&lt;n&gt;</em>".</p>
 </div>
 <div class="paragraph">
 <p>You often want to add additional explanation about the patch,
@@ -1188,7 +1188,7 @@ <h4 id="_format_patch_and_send_email"><code>format-patch</code> and <code>send-e
 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>
+line via <code>git</code> <code>format-patch</code> <code>--notes</code>.</p>
 </div>
 <div id="the-topic-summary" class="paragraph">
 <p><strong>This is EXPERIMENTAL</strong>.</p>
@@ -1229,7 +1229,7 @@ <h4 id="_format_patch_and_send_email"><code>format-patch</code> and <code>send-e
 <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
+that starts with <code>-----BEGIN</code> <code>PGP</code> <code>SIGNED</code> <code>MESSAGE-----</code>.  That is
 not a text/plain, it&#8217;s something else.</p>
 </div>
 </div>
@@ -1440,7 +1440,7 @@ <h2 id="_github_ci">GitHub CI<a id="GHCI"></a></h2>
 <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/&lt;Your GitHub handle&gt;/git/actions/workflows/main.yml</code></p>
+branches here: <code>https://github.com/</code>&lt;Your <code>GitHub</code> <code>handle</code>&gt;<code>/git/actions/workflows/main.yml</code></p>
 </div>
 <div class="paragraph">
 <p>If a branch does not pass all test cases then it will be marked with a
@@ -1550,11 +1550,11 @@ <h3 id="_thunderbird_kmail_gmail">Thunderbird, KMail, GMail</h3>
 <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
+<p>"|" in the *Summary* 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
+<code>git</code> <code>am</code>.  However, if the message is MIME encoded, what is
 piped into the program is the representation you see in your
-<code>*Article*</code> buffer after unwrapping MIME.  This is often not what
+*Article* 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&#8217;s names), and also
 whitespaces (fatal in patches).  Running "C-u g" to display the

ReviewingGuidelines.html

@@ -442,7 +442,7 @@
 <div id="header">
 <h1>Tools for developing Git</h1>
 <div class="details">
-<span id="revdate">2024-10-06</span>
+<span id="revdate">2024-10-10</span>
 </div>
 </div>
 <div id="content">

SubmittingPatches.html

@@ -442,7 +442,7 @@
 <div id="header">
 <h1>Everyday Git With 20 Commands Or So</h1>
 <div class="details">
-<span id="revdate">2024-10-06</span>
+<span id="revdate">2024-10-10</span>
 </div>
 </div>
 <div id="content">

ToolsForGit.html

@@ -481,15 +481,15 @@ <h2 id="_description">DESCRIPTION</h2>
 <p>This command can be performed multiple times before a commit.  It only
 adds the content of the specified file(s) at the time the add command is
 run; if you want subsequent changes included in the next commit, then
-you must run <code>git add</code> again to add the new content to the index.</p>
+you must run <code>git</code> <code>add</code> again to add the new content to the index.</p>
 </div>
 <div class="paragraph">
-<p>The <code>git status</code> command can be used to obtain a summary of which
+<p>The <code>git</code> <code>status</code> command can be used to obtain a summary of which
 files have changes that are staged for the next commit.</p>
 </div>
 <div class="paragraph">
-<p>The <code>git add</code> command will not add ignored files by default.  If any
-ignored files were explicitly specified on the command line, <code>git add</code>
+<p>The <code>git</code> <code>add</code> command will not add ignored files by default.  If any
+ignored files were explicitly specified on the command line, <code>git</code> <code>add</code>
 will fail with a list of ignored files.  Ignored files reached by
 directory recursion or filename globbing performed by Git (quote your
 globs before the shell) will be silently ignored.  The <em>git add</em> command can
@@ -508,7 +508,7 @@ <h2 id="_options">OPTIONS</h2>
 <dl>
 <dt class="hdlist1">&lt;pathspec&gt;&#8230;&#8203;</dt>
 <dd>
-<p>Files to add content from.  Fileglobs (e.g. <code>*.c</code>) can
+<p>Files to add content from.  Fileglobs (e.g. *.<code>c</code>) can
 be given to add all matching files.  Also a
 leading directory name (e.g. <code>dir</code> to add <code>dir/file1</code>
 and <code>dir/file2</code>) can be given to update the index to
@@ -543,7 +543,7 @@ <h2 id="_options">OPTIONS</h2>
 <dt class="hdlist1">--sparse</dt>
 <dd>
 <p>Allow updating index entries outside of the sparse-checkout cone.
-Normally, <code>git add</code> refuses to update index entries whose paths do
+Normally, <code>git</code> <code>add</code> refuses to update index entries whose paths do
 not fit within the sparse-checkout cone, since those files might
 be removed from the working tree without warning. See
 <a href="git-sparse-checkout.html">git-sparse-checkout(1)</a> for more details.</p>
@@ -564,7 +564,7 @@ <h2 id="_options">OPTIONS</h2>
 to review the difference before adding modified contents to the
 index.</p>
 <div class="paragraph">
-<p>This effectively runs <code>add --interactive</code>, but bypasses the
+<p>This effectively runs <code>add</code> <code>--interactive</code>, but bypasses the
 initial command menu and directly jumps to the <code>patch</code> subcommand.
 See &#8220;Interactive mode&#8221; for details.</p>
 </div>
@@ -630,8 +630,8 @@ <h2 id="_options">OPTIONS</h2>
 <p>Record only the fact that the path will be added later. An entry
 for the path is placed in the index with no content. This is
 useful for, among other things, showing the unstaged content of
-such files with <code>git diff</code> and committing them with <code>git commit
--a</code>.</p>
+such files with <code>git</code> <code>diff</code> and committing them with <code>git</code> <code>commit</code>
+<code>-a</code>.</p>
 </dd>
 <dt class="hdlist1">--refresh</dt>
 <dd>
@@ -655,9 +655,9 @@ <h2 id="_options">OPTIONS</h2>
 </dd>
 <dt class="hdlist1">--no-warn-embedded-repo</dt>
 <dd>
-<p>By default, <code>git add</code> will warn when adding an embedded
-repository to the index without using <code>git submodule add</code> to
-create an entry in <code>.gitmodules</code>. This option will suppress the
+<p>By default, <code>git</code> <code>add</code> will warn when adding an embedded
+repository to the index without using <code>git</code> <code>submodule</code> <code>add</code> to
+create an entry in .<code>gitmodules</code>. This option will suppress the
 warning (e.g., if you are manually performing operations on
 submodules).</p>
 </dd>
@@ -708,15 +708,15 @@ <h2 id="_examples">EXAMPLES</h2>
 <div class="ulist">
 <ul>
 <li>
-<p>Adds content from all <code>*.txt</code> files under <code>Documentation</code> directory
+<p>Adds content from all *.<code>txt</code> files under <code>Documentation</code> directory
 and its subdirectories:</p>
 <div class="listingblock">
 <div class="content">
 <pre>$ git add Documentation/\*.txt</pre>
 </div>
 </div>
 <div class="paragraph">
-<p>Note that the asterisk <code>*</code> is quoted from the shell in this
+<p>Note that the asterisk * is quoted from the shell in this
 example; this lets the command include the files from
 subdirectories of <code>Documentation/</code> directory.</p>
 </div>
@@ -772,9 +772,9 @@ <h2 id="_interactive_mode">INTERACTIVE MODE</h2>
 <dt class="hdlist1">status</dt>
 <dd>
 <p>This shows the change between HEAD and index (i.e. what will be
-committed if you say <code>git commit</code>), and between index and
+committed if you say <code>git</code> <code>commit</code>), and between index and
 working tree files (i.e. what you could stage further before
-<code>git commit</code> using <code>git add</code>) for each path.  A sample output
+<code>git</code> <code>commit</code> using <code>git</code> <code>add</code>) for each path.  A sample output
 looks like this:</p>
 <div class="listingblock">
 <div class="content">
@@ -888,7 +888,7 @@ <h2 id="_interactive_mode">INTERACTIVE MODE</h2>
 <h2 id="_editing_patches">EDITING PATCHES</h2>
 <div class="sectionbody">
 <div class="paragraph">
-<p>Invoking <code>git add -e</code> or selecting <code>e</code> from the interactive hunk
+<p>Invoking <code>git</code> <code>add</code> <code>-e</code> or selecting <code>e</code> from the interactive hunk
 selector will open a patch in your editor; after the editor exits, the
 result is applied to the index. You are free to make arbitrary changes
 to the patch, but note that some changes may have confusing results, or