• Check a project’s repository using GitLab UI
  • Enable repository checks for all projects
  • Run a check using the command line
  • What to do if a check failed
  • Repository checks

    You can use git fsck to verify the integrity of all data committed to a repository. GitLab administrators can:

    Check a project’s repository using GitLab UI

    To check a project’s repository using GitLab UI:

    1. On the top bar, select Main menu > Admin .
    2. On the left sidebar, select Overview > Projects .
    3. Select the project to check.
    4. In the Repository check section, select Trigger repository check .

    The checks run asynchronously so it may take a few minutes before the check result is visible on the project page in the Admin Area. If the checks fail, see what to do .

    Enable repository checks for all projects

    Instead of checking repositories manually, GitLab can be configured to run the checks periodically:

    1. On the top bar, select Main menu > Admin .
    2. On the left sidebar, select Settings > Repository ( /admin/application_settings/repository ).
    3. Expand the Repository maintenance section.
    4. Enable Enable repository checks .

    When enabled, GitLab periodically runs a repository check on all project repositories and wiki repositories to detect possible data corruption. A project is checked no more than once per month. Administrators can configure the frequency of repository checks. To edit the frequency:

    If any projects fail their repository checks, all GitLab administrators receive an email notification of the situation. By default, this notification is sent out once a week at midnight at the start of Sunday.

    Repositories with known check failures can be found at /admin/projects?last_repository_check_failed=1 .

    Run a check using the command line

    You can run git fsck using the command line on repositories on Gitaly servers . To locate the repositories:

    1. Go to the storage location for repositories:
    2. For Omnibus GitLab installations, repositories are stored in the /var/opt/gitlab/git-data/repositories directory by default.
    3. For GitLab Helm chart installations, repositories are stored in the /home/git/repositories directory inside the Gitaly pod by default.
    4. Identify the subdirectory that contains the repository that you need to check.
    5. Run the check. For example:

      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 on disk at:

      /var/log/gitlab/gitlab-rails for Omnibus GitLab installations.
    • /home/git/gitlab/log for installations from source.
    • /var/log/gitlab in the Sidekiq pod for GitLab Helm chart installations.

    If periodic repository checks cause false alarms, you can clear all repository check states:

    1. On the top bar, select Main menu > Admin .
    2. On the left sidebar, select Settings > Repository ( /admin/application_settings/repository ).
    3. Expand the Repository maintenance section.
    4. Select Clear all repository checks .

    Error: failed to parse commit <commit SHA> from object database for commit-graph

    You can see a failed to parse commit <commit SHA> from object database for commit-graph error in repository check logs. This error occurs if your commit-graph cache is out of date. The commit-graph cache is an auxiliary cache and is not required for regular Git operations.

    While the message can be safely ignored, see the issue error: Could not read from object database for commit-graph for more details.

    Dangling commit, tag, or blob messages

    Repository check output often includes tags, blobs, and commits that must be pruned:

    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 no longer includes these messages in the check output. Use the --no-dangling option to suppress then when run from the command line.

    Help & feedback

    Docs

    Edit this page to fix an error or add an improvement in a merge request.
    Create an issue to suggest an improvement to this page.

    Product

    Create an issue if there's something you don't like about this feature.
    Propose functionality by submitting a feature request.
    Join First Look to help shape new features.

    Feature availability and product trials

    View pricing to see all GitLab tiers and features, or to upgrade.
    Try GitLab for free with access to all features for 30 days.

    Get Help

    If you didn't find what you were looking for, search the docs .
    If you want help with something specific and could use community support, post on the GitLab forum .
    For problems setting up or using this feature (depending on your GitLab subscription).

    Request support