I find myself with a number of dangling trees and blobs that I need to resolve one way or another. The more I read I don’t find enough context for what appears to be good suggestions. I’m a git user and a reluctant administrator of a self-hosted (dockerized gitlab/mattermost omni-bus install) gitlab installation. I’ve been able to keep up for the most maintenance responsibilities and all seems fine except that I recently got “2 project have failed repository checks” email. After further research, I’ve think I’m down to the source of the problem(s).
Although, I’ve been maintaining our gitlab install and learned a lot, I’m of unsure of some aspect that I hope someone will explain, and maybe help others in similar situation.
I’ve been using our gitlab (admin) online dashboard as well have been accessing a working project (one of 2 repos that are reported as failing repo check) on my laptop.
I found this link to help get started.
According to my repocheck.log:
root@gitlab:/var/log/gitlab/gitlab-rails# more repocheck.log
# Logfile created on 2025-02-12 07:20:05 +0000 by logger.rb/v1.5.3
E, [2025-02-12T07:20:05.779247 #3461243] ERROR -- : <gitlab group>/<repo projectB>: Could not fsck repository: error in blob c2d0824c7ab214331d8c1bc6644254a1b6d464a8: gitmodulesUrl: di
sallowed submodule url: https://<url>:<gitlab group>/<repo projectA>.git
E, [2025-02-13T01:20:04.672318 #3461243] ERROR -- : <gitlab group>/<repo projectA>: Could not fsck repository: error in blob c2d0824c7ab214331d8c1bc6644254a1b6d464a8: gitmodules
Url: disallowed submodule url: https://<url>:<gitlab group>/<repo projectA>.git
E, [2025-02-16T22:23:27.795775 #3461243] ERROR -- :<gitlab group>/<repo projectA>: Could not fsck repository: error in blob c2d0824c7ab214331d8c1bc6644254a1b6d464a8: gitmodules
Url: disallowed submodule url: https://<url>:<gitlab group>/<repo projectA>.gitit
root@gitlab:/var/log/gitlab/gitlab-rails#
I ran the the suggested git -C <Gitaly relative path> fsck and git -C <Gitaly relative path> fsck and triggered another repo check but still did not pass.
Other links suggest I run git fsck and git fsck --unreachable, as well as git show <glob hash> to learn more. However, although I’m seeing lists of “dangling” tree and blog’s and “unreachable” tree and blob’s, and I’m aware of the git tc --prune=now I’m unclear how my next step may impact my code base in progress.
I’ve read what dangling and unreachable blogs are but I’m not getting a sense of what pruning them will do to my project.
I’ve used git show to examine the changes in the dangling commits and generally believe I can lose them because unknowingly I’ve been editing and building without issues–maybe I’ve ignored the odd errors and reimplemented the lost changes. I represent this from the pov of the only person working on these repos (top level project and a number of submodules).
FYI, the repository in question (<https://:/.git> is a submodule of my main project (which itself has no dangling issues) and the 2nd failed check repository (/) is, as I recall, an early attempt to breakout some code to be another submodule. But it was never put into mainstream use, i.e. integrated as a submodule but it was put into a repo but not use as such.
As I encounter this issue I have uncommited changes in the project but it builds.
In conclusion: If I’ve reviewed the changes across my project (saved them dangling pieces in lost-found) and I’m unsure if I’m willing to dismiss the changes contained within, are there any further consequence if I just prune them?
Also, can anyone help me understand some of the mechanics behind these dangling pieces and how gitlab works so I can make better judgments on how to deal with this in the future. Certainly I’d like to understand how this become a problem.
Thanks in Advance.
Environment:
gitlab: 17.8 self-hosted gitlab-ce/mattermost
Ubuntu 22.04
git version 2.34.1
Ubuntu