Add latest changes from gitlab-org/gitlab@16-0-stable-eev16.0.0-rc42

1 files changed, 31 insertions, 4 deletions

diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md
index 08c1df3d5eb..3f715e451a8 100644
--- a/doc/administration/repository_checks.md
+++ b/doc/administration/repository_checks.md
@@ -9,9 +9,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 You can use [`git fsck`](https://git-scm.com/docs/git-fsck) to verify the integrity of all data
 committed to a repository. GitLab administrators can:
 
-- Manually trigger this check for a project, using the GitLab UI.
-- Schedule this check to run automatically for all projects.
-- Run this check from the command line.
+- [Manually trigger this check for a project](#check-a-projects-repository-using-gitlab-ui).
+- [Schedule this check](#enable-repository-checks-for-all-projects) to run automatically for all projects.
+- [Run this check from the command line](#run-a-check-using-the-command-line).
 - Run a [Rake task](raketasks/check.md#repository-integrity) for checking Git repositories, which can be used to run
   `git fsck` against all repositories and generate repository checksums, as a way to compare repositories on different
   servers.
@@ -68,9 +68,13 @@ You can run [`git fsck`](https://git-scm.com/docs/git-fsck) using the command li
 1. Run the check. For example:
 
    ```shell
-   sudo -u git /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/0b/91/0b91...f9.git fsck
+   sudo -u git /opt/gitlab/embedded/bin/git \
+      -C /var/opt/gitlab/git-data/repositories/@hashed/0b/91/0b91...f9.git fsck --no-dangling
    ```
 
+   The error `fatal: detected dubious ownership in repository` means you're running the command
+   using the wrong account. For example, `root`.
+
 ## What to do if a check failed
 
 If a repository check fails, locate the error in the [`repocheck.log` file](logs/index.md#repochecklog) on disk at:
@@ -93,3 +97,26 @@ of date. The `commit-graph` cache is an auxiliary cache and is not required for
 
 While the message can be safely ignored, see the issue [error: Could not read from object database for commit-graph](https://gitlab.com/gitlab-org/gitaly/-/issues/2359)
 for more details.
+
+### Dangling commit, tag, or blob messages
+
+Repository check output often includes tags, blobs, and commits that must be pruned:
+
+```plaintext
+dangling tag 5c6886c774b713a43158aae35c4effdb03a3ceca
+dangling blob 3e268c23fcd736db92e89b31d9f267dd4a50ac4b
+dangling commit 919ff61d8d78c2e3ea9a32701dff70ecbefdd1d7
+```
+
+This is common in Git repositories. They're generated by operations like
+force pushing to branches, because this generates a commit in the repository
+that is not longer referred to by a ref or by another commit.
+
+If a repository check fails, the output is likely to include these warnings.
+
+Ignore these messages, and identify the root cause of the repository check failure
+from the other output.
+
+[GitLab 15.8 and later](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/5230) no
+longer includes these messages in the check output. Use the `--no-dangling` option
+to suppress then when run from the command line.