diff --git a/RelNotes/2.52.0.adoc b/RelNotes/2.52.0.adoc
index ef5f91f..1e41b73 100644
--- a/RelNotes/2.52.0.adoc
+++ b/RelNotes/2.52.0.adoc
@@ -376,3 +376,7 @@
    (merge 1c573a3451 en/doc-merge-tree-describe-merge-base later to maint).
    (merge 84a6bf7965 ja/doc-markup-attached-paragraph-fix later to maint).
    (merge 399694384b kh/doc-patch-id-markup-fix later to maint).
+   (merge 15b8abde07 js/mingw-includes-cleanup later to maint).
+   (merge 3860985105 js/unreachable-workaround-for-no-symlink-head later to maint).
+   (merge b3ac6e737d kh/doc-continued-paragraph-fix later to maint).
+   (merge 2cebca0582 tb/cat-file-objectmode-update later to maint).
diff --git a/git-config.adoc b/git-config.adoc
index 36d2845..cc054fa 100644
--- a/git-config.adoc
+++ b/git-config.adoc
@@ -117,15 +117,15 @@
 
 --comment <message>::
 	Append a comment at the end of new or modified lines.
-
-	If _<message>_ begins with one or more whitespaces followed
-	by "#", it is used as-is.  If it begins with "#", a space is
-	prepended before it is used.  Otherwise, a string " # " (a
-	space followed by a hash followed by a space) is prepended
-	to it.  And the resulting string is placed immediately after
-	the value defined for the variable.  The _<message>_ must
-	not contain linefeed characters (no multi-line comments are
-	permitted).
++
+If _<message>_ begins with one or more whitespaces followed
+by "#", it is used as-is.  If it begins with "#", a space is
+prepended before it is used.  Otherwise, a string " # " (a
+space followed by a hash followed by a space) is prepended
+to it.  And the resulting string is placed immediately after
+the value defined for the variable.  The _<message>_ must
+not contain linefeed characters (no multi-line comments are
+permitted).
 
 --all::
 	With `get`, return all values for a multi-valued key.
diff --git a/git-config.html b/git-config.html
index 47fc8eb..33194ef 100644
--- a/git-config.html
+++ b/git-config.html
@@ -607,17 +607,15 @@
 <dt class="hdlist1">--comment &lt;message&gt;</dt>
 <dd>
 <p>Append a comment at the end of new or modified lines.</p>
-<div class="literalblock">
-<div class="content">
-<pre>If _&lt;message&gt;_ begins with one or more whitespaces followed
-by "#", it is used as-is.  If it begins with "#", a space is
+<div class="paragraph">
+<p>If <em>&lt;message&gt;</em> begins with one or more whitespaces followed
+by "<mark>", it is used as-is.  If it begins with "</mark>", a space is
 prepended before it is used.  Otherwise, a string " # " (a
 space followed by a hash followed by a space) is prepended
 to it.  And the resulting string is placed immediately after
-the value defined for the variable.  The _&lt;message&gt;_ must
+the value defined for the variable.  The <em>&lt;message&gt;</em> must
 not contain linefeed characters (no multi-line comments are
-permitted).</pre>
-</div>
+permitted).</p>
 </div>
 </dd>
 <dt class="hdlist1">--all</dt>
@@ -3093,11 +3091,9 @@
 limited set of supported platforms.  Currently, this includes Windows
 and MacOS.</p>
 </div>
-<div class="literalblock">
-<div class="content">
-<pre>Otherwise, this variable contains the pathname of the "fsmonitor"
-hook command.</pre>
-</div>
+<div class="paragraph">
+<p>Otherwise, this variable contains the pathname of the "fsmonitor"
+hook command.</p>
 </div>
 <div class="paragraph">
 <p>This hook command is used to identify all files that may have changed
@@ -8991,6 +8987,11 @@
 <p>	If this is set to true, <code>git</code> <code>stash</code> <code>apply</code> and <code>git</code> <code>stash</code> <code>pop</code> will
 	behave as if <code>--index</code> was supplied. Defaults to false.
 See the descriptions in <a href="git-stash.html">git-stash(1)</a>.</p>
+<div class="paragraph">
+<p>This also affects invocations of <a href="git-stash.html">git-stash(1)</a> via <code>--autostash</code> from
+commands like <a href="git-merge.html">git-merge(1)</a>, <a href="git-rebase.html">git-rebase(1)</a>, and
+<a href="git-pull.html">git-pull(1)</a>.</p>
+</div>
 </dd>
 <dt class="hdlist1"><code>stash.showIncludeUntracked</code></dt>
 <dd>
@@ -10023,7 +10024,7 @@
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-08-25 14:46:08 -0700
+Last updated 2025-10-20 15:09:57 -0700
 </div>
 </div>
 </body>
diff --git a/git-rev-parse.adoc b/git-rev-parse.adoc
index cc32b4b..18383e5 100644
--- a/git-rev-parse.adoc
+++ b/git-rev-parse.adoc
@@ -174,13 +174,13 @@
 
 	Allow oids to be input from any object format that the current
 	repository supports.
-
-	Specifying "sha1" translates if necessary and returns a sha1 oid.
-
-	Specifying "sha256" translates if necessary and returns a sha256 oid.
-
-	Specifying "storage" translates if necessary and returns an oid in
-	encoded in the storage hash algorithm.
++
+Specifying "sha1" translates if necessary and returns a sha1 oid.
++
+Specifying "sha256" translates if necessary and returns a sha256 oid.
++
+Specifying "storage" translates if necessary and returns an oid in
+encoded in the storage hash algorithm.
 
 Options for Objects
 ~~~~~~~~~~~~~~~~~~~
diff --git a/git-rev-parse.html b/git-rev-parse.html
index 3ec7fba..e5e4207 100644
--- a/git-rev-parse.html
+++ b/git-rev-parse.html
@@ -659,21 +659,15 @@
 <dd>
 <p>Allow oids to be input from any object format that the current
 repository supports.</p>
-<div class="literalblock">
-<div class="content">
-<pre>Specifying "sha1" translates if necessary and returns a sha1 oid.</pre>
+<div class="paragraph">
+<p>Specifying "sha1" translates if necessary and returns a sha1 oid.</p>
 </div>
+<div class="paragraph">
+<p>Specifying "sha256" translates if necessary and returns a sha256 oid.</p>
 </div>
-<div class="literalblock">
-<div class="content">
-<pre>Specifying "sha256" translates if necessary and returns a sha256 oid.</pre>
-</div>
-</div>
-<div class="literalblock">
-<div class="content">
-<pre>Specifying "storage" translates if necessary and returns an oid in
-encoded in the storage hash algorithm.</pre>
-</div>
+<div class="paragraph">
+<p>Specifying "storage" translates if necessary and returns an oid in
+encoded in the storage hash algorithm.</p>
 </div>
 </dd>
 </dl>
@@ -1661,7 +1655,7 @@
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-06-20 18:10:42 -0700
+Last updated 2025-10-20 15:09:57 -0700
 </div>
 </div>
 </body>
diff --git a/git-shortlog.adoc b/git-shortlog.adoc
index d8ab38d..aa92800 100644
--- a/git-shortlog.adoc
+++ b/git-shortlog.adoc
@@ -44,8 +44,8 @@
 	describe each commit.  '<format>' can be any string accepted
 	by the `--format` option of 'git log', such as '* [%h] %s'.
 	(See the "PRETTY FORMATS" section of linkgit:git-log[1].)
-
-	Each pretty-printed commit will be rewrapped before it is shown.
++
+Each pretty-printed commit will be rewrapped before it is shown.
 
 --date=<format>::
 	Show dates formatted according to the given date string. (See
diff --git a/git-shortlog.html b/git-shortlog.html
index 14587b8..a54288c 100644
--- a/git-shortlog.html
+++ b/git-shortlog.html
@@ -502,10 +502,8 @@
 describe each commit.  <em>&lt;format&gt;</em> can be any string accepted
 by the <code>--format</code> option of <em>git log</em>, such as <em>* [%h] %s</em>.
 (See the "PRETTY FORMATS" section of <a href="git-log.html">git-log(1)</a>.)</p>
-<div class="literalblock">
-<div class="content">
-<pre>Each pretty-printed commit will be rewrapped before it is shown.</pre>
-</div>
+<div class="paragraph">
+<p>Each pretty-printed commit will be rewrapped before it is shown.</p>
 </div>
 </dd>
 <dt class="hdlist1">--date=&lt;format&gt;</dt>
@@ -1565,7 +1563,7 @@
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-06-20 18:10:42 -0700
+Last updated 2025-10-20 15:09:57 -0700
 </div>
 </div>
 </body>
diff --git a/git-sparse-checkout.adoc b/git-sparse-checkout.adoc
index 529a8ed..b5fe5da 100644
--- a/git-sparse-checkout.adoc
+++ b/git-sparse-checkout.adoc
@@ -264,34 +264,50 @@
     inconsistent.
 
   * It has edge cases where the "right" behavior is unclear.  Two examples:
-
-    First, two users are in a subdirectory, and the first runs
-       git sparse-checkout set '/toplevel-dir/*.c'
-    while the second runs
-       git sparse-checkout set relative-dir
-    Should those arguments be transliterated into
-       current/subdirectory/toplevel-dir/*.c
-    and
-       current/subdirectory/relative-dir
-    before inserting into the sparse-checkout file?  The user who typed
-    the first command is probably aware that arguments to set/add are
-    supposed to be patterns in non-cone mode, and probably would not be
-    happy with such a transliteration.  However, many gitignore-style
-    patterns are just paths, which might be what the user who typed the
-    second command was thinking, and they'd be upset if their argument
-    wasn't transliterated.
-
-    Second, what should bash-completion complete on for set/add commands
-    for non-cone users?  If it suggests paths, is it exacerbating the
-    problem above?  Also, if it suggests paths, what if the user has a
-    file or directory that begins with either a '!' or '#' or has a '*',
-    '\', '?', '[', or ']' in its name?  And if it suggests paths, will
-    it complete "/pro" to "/proc" (in the root filesystem) rather than to
-    "/progress.txt" in the current directory?  (Note that users are
-    likely to want to start paths with a leading '/' in non-cone mode,
-    for the same reason that .gitignore files often have one.)
-    Completing on files or directories might give nasty surprises in
-    all these cases.
++
+First, two users are in a subdirectory, and the first runs
++
+----
+git sparse-checkout set '/toplevel-dir/*.c'
+----
++
+while the second runs
++
+----
+git sparse-checkout set relative-dir
+----
++
+Should those arguments be transliterated into
++
+----
+current/subdirectory/toplevel-dir/*.c
+----
++
+and
++
+----
+current/subdirectory/relative-dir
+----
++
+before inserting into the sparse-checkout file?  The user who typed
+the first command is probably aware that arguments to set/add are
+supposed to be patterns in non-cone mode, and probably would not be
+happy with such a transliteration.  However, many gitignore-style
+patterns are just paths, which might be what the user who typed the
+second command was thinking, and they'd be upset if their argument
+wasn't transliterated.
++
+Second, what should bash-completion complete on for set/add commands
+for non-cone users?  If it suggests paths, is it exacerbating the
+problem above?  Also, if it suggests paths, what if the user has a
+file or directory that begins with either a '!' or '#' or has a '*',
+'\', '?', '[', or ']' in its name?  And if it suggests paths, will
+it complete "/pro" to "/proc" (in the root filesystem) rather than to
+"/progress.txt" in the current directory?  (Note that users are
+likely to want to start paths with a leading '/' in non-cone mode,
+for the same reason that .gitignore files often have one.)
+Completing on files or directories might give nasty surprises in
+all these cases.
 
   * The excessive flexibility made other extensions essentially
     impractical.  `--sparse-index` is likely impossible in non-cone
diff --git a/git-sparse-checkout.html b/git-sparse-checkout.html
index c900d84..53d9d00 100644
--- a/git-sparse-checkout.html
+++ b/git-sparse-checkout.html
@@ -760,39 +760,59 @@
 </li>
 <li>
 <p>It has edge cases where the "right" behavior is unclear.  Two examples:</p>
-<div class="literalblock">
+<div class="paragraph">
+<p>First, two users are in a subdirectory, and the first runs</p>
+</div>
+<div class="listingblock">
 <div class="content">
-<pre>First, two users are in a subdirectory, and the first runs
-   git sparse-checkout set '/toplevel-dir/*.c'
-while the second runs
-   git sparse-checkout set relative-dir
-Should those arguments be transliterated into
-   current/subdirectory/toplevel-dir/*.c
-and
-   current/subdirectory/relative-dir
-before inserting into the sparse-checkout file?  The user who typed
+<pre>git sparse-checkout set '/toplevel-dir/*.c'</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>while the second runs</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>git sparse-checkout set relative-dir</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Should those arguments be transliterated into</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>current/subdirectory/toplevel-dir/*.c</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>and</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre>current/subdirectory/relative-dir</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>before inserting into the sparse-checkout file?  The user who typed
 the first command is probably aware that arguments to set/add are
 supposed to be patterns in non-cone mode, and probably would not be
 happy with such a transliteration.  However, many gitignore-style
 patterns are just paths, which might be what the user who typed the
-second command was thinking, and they'd be upset if their argument
-wasn't transliterated.</pre>
+second command was thinking, and they&#8217;d be upset if their argument
+wasn&#8217;t transliterated.</p>
 </div>
-</div>
-<div class="literalblock">
-<div class="content">
-<pre>Second, what should bash-completion complete on for set/add commands
+<div class="paragraph">
+<p>Second, what should bash-completion complete on for set/add commands
 for non-cone users?  If it suggests paths, is it exacerbating the
 problem above?  Also, if it suggests paths, what if the user has a
-file or directory that begins with either a '!' or '#' or has a '*',
-'\', '?', '[', or ']' in its name?  And if it suggests paths, will
+file or directory that begins with either a <em>!</em> or <em>#</em> or has a <em>*</em>,
+<em>\</em>, <em>?</em>, <em>[</em>, or <em>]</em> in its name?  And if it suggests paths, will
 it complete "/pro" to "/proc" (in the root filesystem) rather than to
 "/progress.txt" in the current directory?  (Note that users are
-likely to want to start paths with a leading '/' in non-cone mode,
+likely to want to start paths with a leading <em>/</em> in non-cone mode,
 for the same reason that .gitignore files often have one.)
 Completing on files or directories might give nasty surprises in
-all these cases.</pre>
-</div>
+all these cases.</p>
 </div>
 </li>
 <li>
@@ -1045,7 +1065,7 @@
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-06-20 18:10:42 -0700
+Last updated 2025-10-20 15:09:57 -0700
 </div>
 </div>
 </body>