Autogenerated HTML docs for v2.51.1-488-gf2299

Author: gitster

RelNotes/2.52.0.adoc

@@ -100,7 +100,7 @@ Performance, Internal Implementation, Development Support etc.
 
  * CodingGuidelines now spells out how bitfields are to be written.
 
- * Adjust to the way newer versions of cURL selectivel enables tracing
+ * Adjust to the way newer versions of cURL selectively enable tracing
    options, so that our tests can continue to work.
    (merge 1b5a6bfff3 jk/curl-global-trace-components later to maint).
 
@@ -127,6 +127,10 @@ Performance, Internal Implementation, Development Support etc.
  * Documentation for "git log --pretty" options has been updated
    to make it easier to translate.
 
+ * Instead of three library archives (one for git, one for reftable,
+   and one for xdiff), roll everything into a single libgit.a archive.
+   This would help later effort to FFI into Rust.
+
 
 Fixes since v2.51
 -----------------
@@ -212,13 +216,13 @@ including security updates, are included in this release.
    name.
    (merge bcb20dda83 js/doc-gitk-history later to maint).
 
- * Update the instruction to use of GGG in the MyFirstContribution
+ * Update the instructions for using GGG in the MyFirstContribution
    document to say that a GitHub PR could be made against `git/git`
    instead of `gitgitgadget/git`.
    (merge 37001cdbc4 ds/doc-ggg-pr-fork-clarify later to maint).
 
  * Makefile tried to run multiple "cargo build" which would not work
-   very well; serialize their execution to work it around.
+   very well; serialize their execution to work around this problem.
    (merge 0eeacde50e da/cargo-serialize later to maint).
 
  * "git repack --path-walk" lost objects in some corner cases, which
@@ -294,12 +298,12 @@ including security updates, are included in this release.
    updated.
    (merge 54a60e5b38 kh/you-still-use-whatchanged-fix later to maint).
 
- * Clang-format update to let our control macros formatted the way we
+ * Clang-format update to let our control macros be formatted the way we
    had them traditionally, e.g., "for_each_string_list_item()" without
    space before the parentheses.
    (merge 3721541d35 jt/clang-format-foreach-wo-space-before-parenthesis later to maint).
 
- * A few places where an size_t value was cast to curl_off_t without
+ * A few places where a size_t value was cast to curl_off_t without
    checking has been updated to use the existing helper function.
    (merge ecc5749578 js/curl-off-t-fixes later to maint).
 
@@ -329,6 +333,19 @@ including security updates, are included in this release.
    you would get from "git format-patch --notes=..." for a singleton
    patch.
 
+ * The code in "git add -p" and friends to iterate over hunks was
+   riddled with bugs, which has been corrected.
+
+ * A few more things that patch authors can do to help maintainer to
+   keep track of their topics better.
+   (merge 1a41698841 tb/doc-submitting-patches later to maint).
+
+ * An earlier addition to "git diff --no-index A B" to limit the
+   output with pathspec after the two directories misbehaved when
+   these directories were given with a trailing slash, which has been
+   corrected.
+   (merge c0bec06cfe jk/diff-no-index-with-pathspec-fix 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).

SubmittingPatches.adoc

@@ -579,14 +579,27 @@ line via `git format-patch --notes`.
 [[the-topic-summary]]
 *This is EXPERIMENTAL*.
 
-When sending a topic, you can propose a one-paragraph summary that
-should appear in the "What's cooking" report when it is picked up to
-explain the topic.  If you choose to do so, please write a 2-5 line
-paragraph that will fit well in our release notes (see many bulleted
-entries in the Documentation/RelNotes/* files for examples), and make
-it the first paragraph of the cover letter.  For a single-patch
-series, use the space between the three-dash line and the diffstat, as
-described earlier.
+When sending a topic, you can optionally propose a topic name and/or a
+one-paragraph summary that should appear in the "What's cooking"
+report when it is picked up to explain the topic.  If you choose to do
+so, please write a 2-5 line paragraph that will fit well in our
+release notes (see many bulleted entries in the
+Documentation/RelNotes/* files for examples), and make it the first
+(or second, if including a suggested topic name) paragraph of the
+cover letter.  If suggesting a topic name, use the format
+"XX/your-topic-name", where "XX" is a stand-in for the primary
+author's initials, and "your-topic-name" is a brief, dash-delimited
+description of what your topic does.  For a single-patch series, use
+the space between the three-dash line and the diffstat, as described
+earlier.
+
+[[multi-series-efforts]]
+If your patch series is part of a larger effort spanning multiple
+patch series, briefly describe the broader goal, and state where the
+current series fits into that goal.  If you are suggesting a topic
+name as in <<the-topic-summary, section above>>, consider
+"XX/the-broader-goal-part-one", "XX/the-broader-goal-part-two", and so
+on.
 
 [[attachment]]
 Do not attach the patch as a MIME attachment, compressed or not.

SubmittingPatches.html

@@ -1200,14 +1200,27 @@ <h4 id="_format_patch_and_send_email"><code>format-patch</code> and <code>send-e
 <p><strong>This is EXPERIMENTAL</strong>.</p>
 </div>
 <div class="paragraph">
-<p>When sending a topic, you can propose a one-paragraph summary that
-should appear in the "What&#8217;s cooking" report when it is picked up to
-explain the topic.  If you choose to do so, please write a 2-5 line
-paragraph that will fit well in our release notes (see many bulleted
-entries in the Documentation/RelNotes/* files for examples), and make
-it the first paragraph of the cover letter.  For a single-patch
-series, use the space between the three-dash line and the diffstat, as
-described earlier.</p>
+<p>When sending a topic, you can optionally propose a topic name and/or a
+one-paragraph summary that should appear in the "What&#8217;s cooking"
+report when it is picked up to explain the topic.  If you choose to do
+so, please write a 2-5 line paragraph that will fit well in our
+release notes (see many bulleted entries in the
+Documentation/RelNotes/* files for examples), and make it the first
+(or second, if including a suggested topic name) paragraph of the
+cover letter.  If suggesting a topic name, use the format
+"XX/your-topic-name", where "XX" is a stand-in for the primary
+author&#8217;s initials, and "your-topic-name" is a brief, dash-delimited
+description of what your topic does.  For a single-patch series, use
+the space between the three-dash line and the diffstat, as described
+earlier.</p>
+</div>
+<div id="multi-series-efforts" class="paragraph">
+<p>If your patch series is part of a larger effort spanning multiple
+patch series, briefly describe the broader goal, and state where the
+current series fits into that goal.  If you are suggesting a topic
+name as in <a href="#the-topic-summary">section above</a>, consider
+"XX/the-broader-goal-part-one", "XX/the-broader-goal-part-two", and so
+on.</p>
 </div>
 <div id="attachment" class="paragraph">
 <p>Do not attach the patch as a MIME attachment, compressed or not.
@@ -1592,7 +1605,7 @@ <h3 id="_gnus">Gnus</h3>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-08-17 17:22:00 -0700
+Last updated 2025-10-20 13:23:01 -0700
 </div>
 </div>
 </body>

git-add.adoc

@@ -342,10 +342,10 @@ patch::
        d - do not stage this hunk or any of the later hunks in the file
        g - select a hunk to go to
        / - search for a hunk matching the given regex
-       j - leave this hunk undecided, see next undecided hunk
-       J - leave this hunk undecided, see next hunk
-       k - leave this hunk undecided, see previous undecided hunk
-       K - leave this hunk undecided, see previous hunk
+       j - go to the next undecided hunk, roll over at the bottom
+       J - go to the next hunk, roll over at the bottom
+       k - go to the previous undecided hunk, roll over at the top
+       K - go to the previous hunk, roll over at the top
        s - split the current hunk into smaller hunks
        e - manually edit the current hunk
        p - print the current hunk

git-add.html

@@ -872,10 +872,10 @@ <h2 id="_interactive_mode">INTERACTIVE MODE</h2>
 d - do not stage this hunk or any of the later hunks in the file
 g - select a hunk to go to
 / - search for a hunk matching the given regex
-j - leave this hunk undecided, see next undecided hunk
-J - leave this hunk undecided, see next hunk
-k - leave this hunk undecided, see previous undecided hunk
-K - leave this hunk undecided, see previous hunk
+j - go to the next undecided hunk, roll over at the bottom
+J - go to the next hunk, roll over at the bottom
+k - go to the previous undecided hunk, roll over at the top
+K - go to the previous hunk, roll over at the top
 s - split the current hunk into smaller hunks
 e - manually edit the current hunk
 p - print the current hunk
@@ -1045,7 +1045,7 @@ <h2 id="_git">GIT</h2>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2025-09-12 12:13:52 -0700
+Last updated 2025-10-20 13:22:58 -0700
 </div>
 </div>
 </body>