Skip to content

Commit

Permalink
Autogenerated HTML docs for v2.47.0-72-gef8ce8
Browse files Browse the repository at this point in the history
  • Loading branch information
gitster committed Oct 11, 2024
1 parent 55f70b1 commit dc39238
Show file tree
Hide file tree
Showing 224 changed files with 4,821 additions and 4,676 deletions.
2 changes: 1 addition & 1 deletion DecisionMaking.html
Original file line number Diff line number Diff line change
Expand Up @@ -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">
Expand Down
154 changes: 77 additions & 77 deletions MyFirstContribution.html

Large diffs are not rendered by default.

192 changes: 96 additions & 96 deletions MyFirstObjectWalk.html

Large diffs are not rendered by default.

35 changes: 35 additions & 0 deletions RelNotes/2.48.0.txt
Original file line number Diff line number Diff line change
@@ -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).
8 changes: 4 additions & 4 deletions ReviewingGuidelines.html
Original file line number Diff line number Diff line change
Expand Up @@ -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">
Expand Down Expand Up @@ -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
Expand All @@ -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">
Expand Down Expand Up @@ -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>
Expand Down
40 changes: 20 additions & 20 deletions SubmittingPatches.html
Original file line number Diff line number Diff line change
Expand Up @@ -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">
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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">
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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">
Expand Down Expand Up @@ -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">
Expand Down Expand Up @@ -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">
Expand Down Expand Up @@ -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">
Expand Down Expand Up @@ -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,
Expand All @@ -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,
Expand All @@ -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>
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion ToolsForGit.html
Original file line number Diff line number Diff line change
Expand Up @@ -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">
Expand Down
2 changes: 1 addition & 1 deletion everyday.html
Original file line number Diff line number Diff line change
Expand Up @@ -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">
Expand Down
34 changes: 17 additions & 17 deletions git-add.html
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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>
Expand All @@ -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>
Expand Down Expand Up @@ -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>
Expand All @@ -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>
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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">
Expand Down Expand Up @@ -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
Expand Down
Loading

0 comments on commit dc39238

Please sign in to comment.