Autogenerated HTML docs for v2.49.0-rc2

Author: gitster

MyFirstContribution.adoc

@@ -21,7 +21,7 @@ This tutorial aims to summarize the following documents, but the reader may find
 useful additional context:
 
 - `Documentation/SubmittingPatches`
-- `Documentation/howto/new-command.txt`
+- `Documentation/howto/new-command.adoc`
 
 [[getting-help]]
 === Getting Help
@@ -331,7 +331,7 @@ function body:
 apply standard precedence rules. `git_config_get_string_tmp()` will look up
 a specific key ("user.name") and give you the value. There are a number of
 single-key lookup functions like this one; you can see them all (and more info
-about how to use `git_config()`) in `Documentation/technical/api-config.txt`.
+about how to use `git_config()`) in `Documentation/technical/api-config.adoc`.
 
 You should see that the name printed matches the one you see when you run:
 
@@ -461,10 +461,10 @@ $ ./bin-wrappers/git help psuh
 
 Your new command is undocumented! Let's fix that.
 
-Take a look at `Documentation/git-*.txt`. These are the manpages for the
+Take a look at `Documentation/git-*.adoc`. These are the manpages for the
 subcommands that Git knows about. You can open these up and take a look to get
 acquainted with the format, but then go ahead and make a new file
-`Documentation/git-psuh.txt`. Like with most of the documentation in the Git
+`Documentation/git-psuh.adoc`. Like with most of the documentation in the Git
 project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing
 Documentation" section). Use the following template to fill out your own
 manpage:
@@ -543,7 +543,7 @@ Try and run `./bin-wrappers/git psuh -h`. Your command should crash at the end.
 That's because `-h` is a special case which your command should handle by
 printing usage.
 
-Take a look at `Documentation/technical/api-parse-options.txt`. This is a handy
+Take a look at `Documentation/technical/api-parse-options.adoc`. This is a handy
 tool for pulling out options you need to be able to handle, and it takes a
 usage string.
 
@@ -1088,14 +1088,14 @@ This gives reviewers a summary of what they're in for when reviewing your topic.
 The one generated for `psuh` from the sample implementation looks like this:
 
 ----
- Documentation/git-psuh.txt | 40 +++++++++++++++++++++
- Makefile                   |  1 +
- builtin.h                  |  1 +
- builtin/psuh.c             | 73 ++++++++++++++++++++++++++++++++++++++
- git.c                      |  1 +
- t/t9999-psuh-tutorial.sh   | 12 +++++++
+ Documentation/git-psuh.adoc | 40 +++++++++++++++++++++
+ Makefile                    |  1 +
+ builtin.h                   |  1 +
+ builtin/psuh.c              | 73 ++++++++++++++++++++++++++++++++++++++
+ git.c                       |  1 +
+ t/t9999-psuh-tutorial.sh    | 12 +++++++
  6 files changed, 128 insertions(+)
- create mode 100644 Documentation/git-psuh.txt
+ create mode 100644 Documentation/git-psuh.adoc
  create mode 100644 builtin/psuh.c
  create mode 100755 t/t9999-psuh-tutorial.sh
 ----

MyFirstContribution.html

@@ -470,7 +470,7 @@ <h3 id="related-reading"><a class="anchor" href="#related-reading"></a>Related R
 <p><code>Documentation/SubmittingPatches</code></p>
 </li>
 <li>
-<p><code>Documentation/howto/new-command.txt</code></p>
+<p><code>Documentation/howto/new-command.adoc</code></p>
 </li>
 </ul>
 </div>
@@ -870,7 +870,7 @@ <h3 id="implementation"><a class="anchor" href="#implementation"></a>Implementat
 apply standard precedence rules. <code>git_config_get_string_tmp</code>() will look up
 a specific key ("user.name") and give you the value. There are a number of
 single-key lookup functions like this one; you can see them all (and more info
-about how to use <code>git_config</code>()) in <code>Documentation/technical/api-config.txt</code>.</p>
+about how to use <code>git_config</code>()) in <code>Documentation/technical/api-config.adoc</code>.</p>
 </div>
 <div class="paragraph">
 <p>You should see that the name printed matches the one you see when you run:</p>
@@ -1041,10 +1041,10 @@ <h3 id="add-documentation"><a class="anchor" href="#add-documentation"></a>Addin
 <p>Your new command is undocumented! Let&#8217;s fix that.</p>
 </div>
 <div class="paragraph">
-<p>Take a look at <code>Documentation/git-</code>*.<code>txt</code>. These are the manpages for the
+<p>Take a look at <code>Documentation/git-</code>*.<code>adoc</code>. These are the manpages for the
 subcommands that Git knows about. You can open these up and take a look to get
 acquainted with the format, but then go ahead and make a new file
-<code>Documentation/git-psuh.txt</code>. Like with most of the documentation in the Git
+<code>Documentation/git-psuh.adoc</code>. Like with most of the documentation in the Git
 project, help pages are written with AsciiDoc (see CodingGuidelines, "Writing
 Documentation" section). Use the following template to fill out your own
 manpage:</p>
@@ -1142,7 +1142,7 @@ <h3 id="add-usage"><a class="anchor" href="#add-usage"></a>Adding Usage Text</h3
 printing usage.</p>
 </div>
 <div class="paragraph">
-<p>Take a look at <code>Documentation/technical/api-parse-options.txt</code>. This is a handy
+<p>Take a look at <code>Documentation/technical/api-parse-options.adoc</code>. This is a handy
 tool for pulling out options you need to be able to handle, and it takes a
 usage string.</p>
 </div>
@@ -1847,14 +1847,14 @@ <h3 id="preparing-cover-letter"><a class="anchor" href="#preparing-cover-letter"
 </div>
 <div class="listingblock">
 <div class="content">
-<pre> Documentation/git-psuh.txt | 40 +++++++++++++++++++++
- Makefile                   |  1 +
- builtin.h                  |  1 +
- builtin/psuh.c             | 73 ++++++++++++++++++++++++++++++++++++++
- git.c                      |  1 +
- t/t9999-psuh-tutorial.sh   | 12 +++++++
+<pre> Documentation/git-psuh.adoc | 40 +++++++++++++++++++++
+ Makefile                    |  1 +
+ builtin.h                   |  1 +
+ builtin/psuh.c              | 73 ++++++++++++++++++++++++++++++++++++++
+ git.c                       |  1 +
+ t/t9999-psuh-tutorial.sh    | 12 +++++++
  6 files changed, 128 insertions(+)
- create mode 100644 Documentation/git-psuh.txt
+ create mode 100644 Documentation/git-psuh.adoc
  create mode 100644 builtin/psuh.c
  create mode 100755 t/t9999-psuh-tutorial.sh</pre>
 </div>
@@ -2239,7 +2239,7 @@ <h3 id="after-approval"><a class="anchor" href="#after-approval"></a>After Revie
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-02-14 21:38:14 -0800
+Last updated 2025-03-10 09:41:59 -0700
 </div>
 </div>
 </body>

MyFirstObjectWalk.adoc

@@ -15,7 +15,7 @@ revision walk is used for operations like `git log`.
 
 === Related Reading
 
-- `Documentation/user-manual.txt` under "Hacking Git" contains some coverage of
+- `Documentation/user-manual.adoc` under "Hacking Git" contains some coverage of
   the revision walker in its various incarnations.
 - `revision.h`
 - https://eagain.net/articles/git-for-computer-scientists/[Git for Computer Scientists]
@@ -112,7 +112,7 @@ $ GIT_TRACE=1 ./bin-wrappers/git walken
 ----
 
 NOTE: For a more exhaustive overview of the new command process, take a look at
-`Documentation/MyFirstContribution.txt`.
+`Documentation/MyFirstContribution.adoc`.
 
 NOTE: A reference implementation can be found at
 https://github.com/nasamuffin/git/tree/revwalk.
@@ -132,7 +132,7 @@ used to track the allocated size of the list.
 Per entry, we find:
 
 `item` is the object provided upon which to base the object walk. Items in Git
-can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.txt`.)
+can be blobs, trees, commits, or tags. (See `Documentation/gittutorial-2.adoc`.)
 
 `name` is the object ID (OID) of the object - a hex string you may be familiar
 with from using Git to organize your source in the past. Check the tutorial
@@ -141,7 +141,7 @@ from.
 
 `whence` indicates some information about what to do with the parents of the
 specified object. We'll explore this flag more later on; take a look at
-`Documentation/revisions.txt` to get an idea of what could set the `whence`
+`Documentation/revisions.adoc` to get an idea of what could set the `whence`
 value.
 
 `flags` are used to hint the beginning of the revision walk and are the first
@@ -153,7 +153,7 @@ can be used during the walk, as well.
 
 This one is quite a bit longer, and many fields are only used during the walk
 by `revision.c` - not configuration options. Most of the configurable flags in
-`struct rev_info` have a mirror in `Documentation/rev-list-options.txt`. It's a
+`struct rev_info` have a mirror in `Documentation/rev-list-options.adoc`. It's a
 good idea to take some time and read through that document.
 
 == Basic Commit Walk
@@ -710,7 +710,7 @@ objects grows along with the Git project.
 === Adding a Filter
 
 There are a handful of filters that we can apply to the object walk laid out in
-`Documentation/rev-list-options.txt`. These filters are typically useful for
+`Documentation/rev-list-options.adoc`. These filters are typically useful for
 operations such as creating packfiles or performing a partial clone. They are
 defined in `list-objects-filter-options.h`. For the purposes of this tutorial we
 will use the "tree:1" filter, which causes the walk to omit all trees and blobs

MyFirstObjectWalk.html

@@ -465,7 +465,7 @@ <h3 id="_related_reading">Related Reading</h3>
 <div class="ulist">
 <ul>
 <li>
-<p><code>Documentation/user-manual.txt</code> under "Hacking Git" contains some coverage of
+<p><code>Documentation/user-manual.adoc</code> under "Hacking Git" contains some coverage of
 the revision walker in its various incarnations.</p>
 </li>
 <li>
@@ -603,7 +603,7 @@ <h2 id="_setting_up">Setting Up</h2>
 </td>
 <td class="content">
 For a more exhaustive overview of the new command process, take a look at
-<code>Documentation/MyFirstContribution.txt</code>.
+<code>Documentation/MyFirstContribution.adoc</code>.
 </td>
 </tr>
 </table>
@@ -642,7 +642,7 @@ <h3 id="_struct_rev_cmdline_info"><code>struct</code> <code>rev_cmdline_info</co
 </div>
 <div class="paragraph">
 <p><code>item</code> is the object provided upon which to base the object walk. Items in Git
-can be blobs, trees, commits, or tags. (See <code>Documentation/gittutorial-2.txt</code>.)</p>
+can be blobs, trees, commits, or tags. (See <code>Documentation/gittutorial-2.adoc</code>.)</p>
 </div>
 <div class="paragraph">
 <p><code>name</code> is the object ID (OID) of the object - a hex string you may be familiar
@@ -653,7 +653,7 @@ <h3 id="_struct_rev_cmdline_info"><code>struct</code> <code>rev_cmdline_info</co
 <div class="paragraph">
 <p><code>whence</code> indicates some information about what to do with the parents of the
 specified object. We&#8217;ll explore this flag more later on; take a look at
-<code>Documentation/revisions.txt</code> to get an idea of what could set the <code>whence</code>
+<code>Documentation/revisions.adoc</code> to get an idea of what could set the <code>whence</code>
 value.</p>
 </div>
 <div class="paragraph">
@@ -668,7 +668,7 @@ <h3 id="_struct_rev_info"><code>struct</code> <code>rev_info</code></h3>
 <div class="paragraph">
 <p>This one is quite a bit longer, and many fields are only used during the walk
 by <code>revision.c</code> - not configuration options. Most of the configurable flags in
-<code>struct</code> <code>rev_info</code> have a mirror in <code>Documentation/rev-list-options.txt</code>. It&#8217;s a
+<code>struct</code> <code>rev_info</code> have a mirror in <code>Documentation/rev-list-options.adoc</code>. It&#8217;s a
 good idea to take some time and read through that document.</p>
 </div>
 </div>
@@ -1428,7 +1428,7 @@ <h2 id="_basic_object_walk">Basic Object Walk</h2>
 <h3 id="_adding_a_filter_2">Adding a Filter</h3>
 <div class="paragraph">
 <p>There are a handful of filters that we can apply to the object walk laid out in
-<code>Documentation/rev-list-options.txt</code>. These filters are typically useful for
+<code>Documentation/rev-list-options.adoc</code>. These filters are typically useful for
 operations such as creating packfiles or performing a partial clone. They are
 defined in <code>list-objects-filter-options.h</code>. For the purposes of this tutorial we
 will use the "tree:1" filter, which causes the walk to omit all trees and blobs
@@ -1675,7 +1675,7 @@ <h2 id="_wrapping_up">Wrapping Up</h2>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-02-14 21:38:14 -0800
+Last updated 2025-03-10 09:41:59 -0700
 </div>
 </div>
 </body>

SubmittingPatches.html

@@ -1584,7 +1584,7 @@ <h3 id="_gnus">Gnus</h3>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-03-04 08:35:31 -0800
+Last updated 2025-03-10 09:42:02 -0700
 </div>
 </div>
 </body>

gitattributes.adoc

@@ -513,7 +513,7 @@ If the filter command (a string value) is defined via
 `filter.<driver>.process` then Git can process all blobs with a
 single filter invocation for the entire life of a single Git
 command. This is achieved by using the long-running process protocol
-(described in technical/long-running-process-protocol.txt).
+(described in Documentation/technical/long-running-process-protocol.adoc).
 
 When Git encounters the first file that needs to be cleaned or smudged,
 it starts the filter and performs the handshake. In the handshake, the
@@ -1177,11 +1177,11 @@ integer has a meaningful effect.
 
 For example, this line in `.gitattributes` can be used to tell the merge
 machinery to leave much longer (instead of the usual 7-character-long)
-conflict markers when merging the file `Documentation/git-merge.txt`
+conflict markers when merging the file `Documentation/git-merge.adoc`
 results in a conflict.
 
 ------------------------
-Documentation/git-merge.txt	conflict-marker-size=32
+Documentation/git-merge.adoc	conflict-marker-size=32
 ------------------------
 
 

gitattributes.html

@@ -1070,7 +1070,7 @@ <h4 id="_long_running_filter_process">Long Running Filter Process</h4>
 <code>filter.</code><em>&lt;driver&gt;</em><code>.process</code> then Git can process all blobs with a
 single filter invocation for the entire life of a single Git
 command. This is achieved by using the long-running process protocol
-(described in technical/long-running-process-protocol.txt).</p>
+(described in Documentation/technical/long-running-process-protocol.adoc).</p>
 </div>
 <div class="paragraph">
 <p>When Git encounters the first file that needs to be cleaned or smudged,
@@ -1882,12 +1882,12 @@ <h4 id="_conflict_marker_size"><code>conflict-marker-size</code></h4>
 <div class="paragraph">
 <p>For example, this line in .<code>gitattributes</code> can be used to tell the merge
 machinery to leave much longer (instead of the usual 7-character-long)
-conflict markers when merging the file <code>Documentation/git-merge.txt</code>
+conflict markers when merging the file <code>Documentation/git-merge.adoc</code>
 results in a conflict.</p>
 </div>
 <div class="listingblock">
 <div class="content">
-<pre>Documentation/git-merge.txt     conflict-marker-size=32</pre>
+<pre>Documentation/git-merge.adoc    conflict-marker-size=32</pre>
 </div>
 </div>
 </div>
@@ -2125,7 +2125,7 @@ <h2 id="_git">GIT</h2>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-02-21 13:44:53 -0800
+Last updated 2025-03-10 09:41:59 -0700
 </div>
 </div>
 </body>

gitrepository-layout.adoc

@@ -152,6 +152,7 @@ config.worktree::
 	working directory in multiple working directory setup (see
 	linkgit:git-worktree[1]).
 
+ifndef::with-breaking-changes[]
 branches::
 	A deprecated way to store shorthands to be used
 	to specify a URL to 'git fetch', 'git pull' and 'git push'.
@@ -164,6 +165,7 @@ branches::
 	"$GIT_COMMON_DIR/branches" will be used instead.
 +
 Git will stop reading remotes from this directory in Git 3.0.
+endif::with-breaking-changes[]
 
 hooks::
 	Hooks are customization scripts used by various Git
@@ -231,6 +233,7 @@ info/sparse-checkout::
 	This file stores sparse checkout patterns.
 	See also: linkgit:git-read-tree[1].
 
+ifndef::with-breaking-changes[]
 remotes::
 	Stores shorthands for URL and default refnames for use
 	when interacting with remote repositories via 'git fetch',
@@ -241,6 +244,7 @@ remotes::
 	"$GIT_COMMON_DIR/remotes" will be used instead.
 +
 Git will stop reading remotes from this directory in Git 3.0.
+endif::with-breaking-changes[]
 
 logs::
 	Records of changes made to refs are stored in this directory.

gitrepository-layout.html

@@ -932,7 +932,7 @@ <h2 id="_git">GIT</h2>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-02-14 21:38:14 -0800
+Last updated 2025-03-10 09:41:59 -0700
 </div>
 </div>
 </body>