Autogenerated HTML docs for v2.51.1-549-g4e98b7

Author: gitster

RelNotes/2.52.0.adoc

@@ -55,6 +55,8 @@ UI, Workflows & Features
    (e.g. blame.ignorerevsfile) can be marked as optional by prefixing
    ":(optoinal)" before its value.
 
+ * Show 'P'ipe command in "git add -p".
+
 
 Performance, Internal Implementation, Development Support etc.
 --------------------------------------------------------------
@@ -133,6 +135,9 @@ Performance, Internal Implementation, Development Support etc.
 
  * The beginning of SHA1-SHA256 interoperability work.
 
+ * Build procedure for a few credential helpers (in contrib/) have
+   been updated.
+
 
 Fixes since v2.51
 -----------------
@@ -352,6 +357,25 @@ including security updates, are included in this release.
    corrected.
    (merge c0bec06cfe jk/diff-no-index-with-pathspec-fix later to maint).
 
+ * The "--short" option of "git status" that meant output for humans
+   and "-z" option to show NUL delimited output format did not mix
+   well, and colored some but not all things.  The command has been
+   updated to color all elements consistently in such a case.
+   (merge 50927f4f68 jk/status-z-short-fix later to maint).
+
+ * Unicode width table update.
+   (merge 330a54099e tb/unicode-width-table-17 later to maint).
+
+ * GPG signing test set-up has been broken for a year, which has been
+   corrected.
+   (merge 516bf45749 jc/t1016-setup-fix later to maint).
+
+ * Recent OpenSSH creates the Unix domain socket to communicate with
+   ssh-agent under $HOME instead of /tmp, which causes our test to
+   fail doe to overly long pathname in our test environment, which has
+   been worked around by using "ssh-agent -T".
+   (merge b7fb2194b9 ps/t7528-ssh-agent-uds-workaround later to maint).
+
  * Other code cleanup, docfix, build fix, etc.
    (merge 823d537fa7 kh/doc-git-log-markup-fix later to maint).
    (merge cf7efa4f33 rj/t6137-cygwin-fix later to maint).

git-add.adoc

@@ -349,6 +349,7 @@ patch::
        s - split the current hunk into smaller hunks
        e - manually edit the current hunk
        p - print the current hunk
+       P - print the current hunk using the pager
        ? - print help
 +
 After deciding the fate for all hunks, if there is any hunk

git-add.html

@@ -879,6 +879,7 @@ <h2 id="_interactive_mode">INTERACTIVE MODE</h2>
 s - split the current hunk into smaller hunks
 e - manually edit the current hunk
 p - print the current hunk
+P - print the current hunk using the pager
 ? - print help</pre>
 </div>
 </div>
@@ -1045,7 +1046,7 @@ <h2 id="_git">GIT</h2>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-10-20 13:22:58 -0700
+Last updated 2025-10-24 14:37:25 -0700
 </div>
 </div>
 </body>

technical/commit-graph.adoc

@@ -39,6 +39,7 @@ A consumer may load the following info for a commit from the graph:
 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 number v1)
 
@@ -158,7 +159,8 @@ number of commits in the full history. By creating a "chain" of commit-graphs,
 we enable fast writes of new commit data without rewriting the entire commit
 history -- at least, most of the time.
 
-## File Layout
+File Layout
+~~~~~~~~~~~
 
 A commit-graph chain uses multiple files, and we use a fixed naming convention
 to organize these files. Each commit-graph file has a name
@@ -170,11 +172,11 @@ hashes for the files in order from "lowest" to "highest".
 
 For example, if the `commit-graph-chain` file contains the lines
 
-```
+----
 	{hash0}
 	{hash1}
 	{hash2}
-```
+----
 
 then the commit-graph chain looks like the following diagram:
 
@@ -213,7 +215,8 @@ specifying the hashes of all files in the lower layers. In the above example,
 `graph-{hash1}.graph` contains `{hash0}` while `graph-{hash2}.graph` contains
 `{hash0}` and `{hash1}`.
 
-## Merging commit-graph files
+Merging commit-graph files
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If we only added a new commit-graph file on every write, we would run into a
 linear search problem through many commit-graph files.  Instead, we use a merge
@@ -225,6 +228,7 @@ is determined by the merge strategy that the files should collapse to
 the commits in `graph-{hash1}` should be combined into a new `graph-{hash3}`
 file.
 
+....
 			    +---------------------+
 			    |                     |
 			    |    (new commits)    |
@@ -250,21 +254,23 @@ file.
  |                       |
  |                       |
  +-----------------------+
+....
 
 During this process, the commits to write are combined, sorted and we write the
 contents to a temporary file, all while holding a `commit-graph-chain.lock`
 lock-file.  When the file is flushed, we rename it to `graph-{hash3}`
 according to the computed `{hash3}`. Finally, we write the new chain data to
 `commit-graph-chain.lock`:
 
-```
+----
 	{hash3}
 	{hash0}
-```
+----
 
 We then close the lock-file.
 
-## Merge Strategy
+Merge Strategy
+~~~~~~~~~~~~~~
 
 When writing a set of commits that do not exist in the commit-graph stack of
 height N, we default to creating a new file at level N + 1. We then decide to
@@ -289,7 +295,8 @@ The merge strategy values (2 for the size multiple, 64,000 for the maximum
 number of commits) could be extracted into config settings for full
 flexibility.
 
-## Handling Mixed Generation Number Chains
+Handling Mixed Generation Number Chains
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 With the introduction of generation number v2 and generation data chunk, the
 following scenario is possible:
@@ -318,7 +325,8 @@ have corrected commit dates when written by compatible versions of Git. Thus,
 rewriting split commit-graph as a single file (`--split=replace`) creates a
 single layer with corrected commit dates.
 
-## Deleting graph-{hash} files
+Deleting graph-\{hash\} files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 After a new tip file is written, some `graph-{hash}` files may no longer
 be part of a chain. It is important to remove these files from disk, eventually.
@@ -333,7 +341,8 @@ files whose modified times are older than a given expiry window. This window
 defaults to zero, but can be changed using command-line arguments or a config
 setting.
 
-## Chains across multiple object directories
+Chains across multiple object directories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In a repo with alternates, we look for the `commit-graph-chain` file starting
 in the local object directory and then in each alternate. The first file that

technical/commit-graph.html

@@ -513,9 +513,17 @@ <h1>Git Commit-Graph Design Notes</h1>
 <p>Values 1-4 satisfy the requirements of parse_commit_gently().</p>
 </div>
 <div class="paragraph">
-<p>There are two definitions of generation number:
-1. Corrected committer dates (generation number v2)
-2. Topological levels (generation number v1)</p>
+<p>There are two definitions of generation number:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Corrected committer dates (generation number v2)</p>
+</li>
+<li>
+<p>Topological levels (generation number v1)</p>
+</li>
+</ol>
 </div>
 <div class="paragraph">
 <p>Define "corrected committer date" of a commit recursively as follows:</p>
@@ -683,11 +691,8 @@ <h2 id="_commit_graphs_chains">Commit-Graphs Chains</h2>
 we enable fast writes of new commit data without rewriting the entire commit
 history&#8201;&#8212;&#8201;at least, most of the time.</p>
 </div>
-</div>
-</div>
-<div class="sect1">
-<h2 id="_file_layout">File Layout</h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_file_layout">File Layout</h3>
 <div class="paragraph">
 <p>A commit-graph chain uses multiple files, and we use a fixed naming convention
 to organize these files. Each commit-graph file has a name
@@ -702,9 +707,9 @@ <h2 id="_file_layout">File Layout</h2>
 </div>
 <div class="listingblock">
 <div class="content">
-<pre class="highlight"><code>        {hash0}
+<pre>        {hash0}
         {hash1}
-        {hash2}</code></pre>
+        {hash2}</pre>
 </div>
 </div>
 <div class="paragraph">
@@ -751,10 +756,8 @@ <h2 id="_file_layout">File Layout</h2>
 {hash0} and {hash1}.</p>
 </div>
 </div>
-</div>
-<div class="sect1">
-<h2 id="_merging_commit_graph_files">Merging commit-graph files</h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_merging_commit_graph_files">Merging commit-graph files</h3>
 <div class="paragraph">
 <p>If we only added a new commit-graph file on every write, we would run into a
 linear search problem through many commit-graph files.  Instead, we use a merge
@@ -769,31 +772,31 @@ <h2 id="_merging_commit_graph_files">Merging commit-graph files</h2>
 </div>
 <div class="literalblock">
 <div class="content">
-<pre>		    +---------------------+
-		    |                     |
-		    |    (new commits)    |
-		    |                     |
-		    +---------------------+
-		    |                     |
-+-----------------------+  +---------------------+
-|  graph-{hash2}        |-&gt;|                     |
-+-----------------------+  +---------------------+
-  |                 |                     |
-+-----------------------+  +---------------------+
-|                       |  |                     |
-|  graph-{hash1}        |-&gt;|                     |
-|                       |  |                     |
-+-----------------------+  +---------------------+
-  |                  tmp_graphXXX
-+-----------------------+
-|                       |
-|                       |
-|                       |
-|  graph-{hash0}        |
-|                       |
-|                       |
-|                       |
-+-----------------------+</pre>
+<pre>                            +---------------------+
+                            |                     |
+                            |    (new commits)    |
+                            |                     |
+                            +---------------------+
+                            |                     |
+ +-----------------------+  +---------------------+
+ |  graph-{hash2}        |-&gt;|                     |
+ +-----------------------+  +---------------------+
+          |                 |                     |
+ +-----------------------+  +---------------------+
+ |                       |  |                     |
+ |  graph-{hash1}        |-&gt;|                     |
+ |                       |  |                     |
+ +-----------------------+  +---------------------+
+          |                  tmp_graphXXX
+ +-----------------------+
+ |                       |
+ |                       |
+ |                       |
+ |  graph-{hash0}        |
+ |                       |
+ |                       |
+ |                       |
+ +-----------------------+</pre>
 </div>
 </div>
 <div class="paragraph">
@@ -805,18 +808,16 @@ <h2 id="_merging_commit_graph_files">Merging commit-graph files</h2>
 </div>
 <div class="listingblock">
 <div class="content">
-<pre class="highlight"><code>        {hash3}
-        {hash0}</code></pre>
+<pre>        {hash3}
+        {hash0}</pre>
 </div>
 </div>
 <div class="paragraph">
 <p>We then close the lock-file.</p>
 </div>
 </div>
-</div>
-<div class="sect1">
-<h2 id="_merge_strategy">Merge Strategy</h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_merge_strategy">Merge Strategy</h3>
 <div class="paragraph">
 <p>When writing a set of commits that do not exist in the commit-graph stack of
 height N, we default to creating a new file at level N + 1. We then decide to
@@ -851,10 +852,8 @@ <h2 id="_merge_strategy">Merge Strategy</h2>
 flexibility.</p>
 </div>
 </div>
-</div>
-<div class="sect1">
-<h2 id="_handling_mixed_generation_number_chains">Handling Mixed Generation Number Chains</h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_handling_mixed_generation_number_chains">Handling Mixed Generation Number Chains</h3>
 <div class="paragraph">
 <p>With the introduction of generation number v2 and generation data chunk, the
 following scenario is possible:</p>
@@ -895,10 +894,8 @@ <h2 id="_handling_mixed_generation_number_chains">Handling Mixed Generation Numb
 single layer with corrected commit dates.</p>
 </div>
 </div>
-</div>
-<div class="sect1">
-<h2 id="_deleting_graph_hash_files">Deleting graph-{hash} files</h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_deleting_graph_hash_files">Deleting graph-{hash} files</h3>
 <div class="paragraph">
 <p>After a new tip file is written, some <code>graph-</code>{hash} files may no longer
 be part of a chain. It is important to remove these files from disk, eventually.
@@ -915,10 +912,8 @@ <h2 id="_deleting_graph_hash_files">Deleting graph-{hash} files</h2>
 setting.</p>
 </div>
 </div>
-</div>
-<div class="sect1">
-<h2 id="_chains_across_multiple_object_directories">Chains across multiple object directories</h2>
-<div class="sectionbody">
+<div class="sect2">
+<h3 id="_chains_across_multiple_object_directories">Chains across multiple object directories</h3>
 <div class="paragraph">
 <p>In a repo with alternates, we look for the <code>commit-graph-chain</code> file starting
 in the local object directory and then in each alternate. The first file that
@@ -966,6 +961,7 @@ <h2 id="_chains_across_multiple_object_directories">Chains across multiple objec
 </div>
 </div>
 </div>
+</div>
 <div class="sect1">
 <h2 id="_related_links">Related Links</h2>
 <div class="sectionbody">
@@ -1012,7 +1008,7 @@ <h2 id="_related_links">Related Links</h2>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-06-20 18:10:42 -0700
+Last updated 2025-10-24 14:37:25 -0700
 </div>
 </div>
 </body>