Merge tag 'v2.29.0-rc1' of github.com:git/git

Git 2.29-rc1

* tag 'v2.29.0-rc1' of github.com:git/git:
  Git 2.29-rc1
  doc: fix the bnf like style of some commands
  doc: git-remote fix ups
  doc: use linkgit macro where needed.
  git-bisect-lk2009: make continuation of list indented
  ci: do not skip tagged revisions in GitHub workflows
  ci: skip GitHub workflow runs for already-tested commits/trees
  tests: avoid using the branch name `main`
  t1415: avoid using `main` as ref name
  Makefile: ASCII-sort += lists
  help: do not expect built-in commands to be hardlinked
  index-pack: make get_base_data() comment clearer
  index-pack: drop type_cas mutex
  index-pack: restore "resolving deltas" progress meter
  compat/mingw.h: drop extern from function declaration
  GitHub workflow: automatically follow minor updates of setup-msbuild
  t5534: split stdout and stderr redirection

1 files changed, 8 insertions, 8 deletions

diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt
index 3ba49e85b7..f3d9566c89 100644
--- a/Documentation/git-bisect-lk2009.txt
+++ b/Documentation/git-bisect-lk2009.txt
@@ -473,7 +473,7 @@ Z-Z
 -------------
 
 2) starting from the "good" ends of the graph, associate to each
-commit the number of ancestors it has plus one
+   commit the number of ancestors it has plus one
 
 For example with the following graph where H is the "bad" commit and A
 and D are some parents of some "good" commits:
@@ -514,7 +514,7 @@ D---E
 -------------
 
 4) the best bisection point is the commit with the highest associated
-number
+   number
 
 So in the above example the best bisection point is commit C.
 
@@ -580,8 +580,8 @@ good or a bad commit does not give more or less information).
 
 Let's also suppose that we have a cleaned up graph like one after step
 1) in the bisection algorithm above. This means that we can measure
-the information we get in terms of number of commit we can remove from
-the graph..
+   the information we get in terms of number of commit we can remove
+   from the graph..
 
 And let's take a commit X in the graph.
 
@@ -689,18 +689,18 @@ roughly the following steps:
 6) sort the commit by decreasing associated value
 
 7) if the first commit has not been skipped, we can return it and stop
-here
+   here
 
 8) otherwise filter out all the skipped commits in the sorted list
 
 9) use a pseudo random number generator (PRNG) to generate a random
-number between 0 and 1
+   number between 0 and 1
 
 10) multiply this random number with its square root to bias it toward
-0
+    0
 
 11) multiply the result by the number of commits in the filtered list
-to get an index into this list
+    to get an index into this list
 
 12) return the commit at the computed index