4

I have a repo that when I run git fsck --full, I got a long list of broken commit ids:

Checking object directories: 100% (256/256), done.
Checking objects: 100% (861/861), done.
error: Could not read 0f514378e088c610cbeb8b047c63d4209736d1f9
failed to parse commit 0f514378e088c610cbeb8b047c63d4209736d1f9 from object database for commit-graph
error: Could not read 1e77fe5a6c4bec9bc9bd7ac5c00f2bbe98249b44
failed to parse commit 1e77fe5a6c4bec9bc9bd7ac5c00f2bbe98249b44 from object database for commit-graph
error: Could not read 2a86db8a8c83ac0fdb5050efa63b518fbeaf8146
failed to parse commit 2a86db8a8c83ac0fdb5050efa63b518fbeaf8146 from object database for commit-graph
error: Could not read 2d898d27a8858cfba7db93f79ada3bdca181758d
failed to parse commit 2d898d27a8858cfba7db93f79ada3bdca181758d from object database for commit-graph
...
error: Could not read fc80facb8f8bf3a5972c51b2e9ae5e63552db2f0
failed to parse commit fc80facb8f8bf3a5972c51b2e9ae5e63552db2f0 from object database for commit-graph
Verifying commits in commit graph: 100% (28/28), done.

I just could not figure out how to delete them. I tried git gc, git prune, none of them works...

also I have a commit that can be shown as diff with git show <commit_id>, but when I run git branch --contains <commit_id> , no branch is found, so I believe that is a dangling commit, but again, I tried everything I found on google. None works.

The commands I tried.

git prune --expire now
git gc --prune=now
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch filename --prune-empty --tag-name-filter cat -- --all"
...

5
  • For the commit you mention at the end, it could be reachable from no local branch, but be tagged, or be in the ancestry of a tagged commit, or even on a remote-tracking branch that you never checked out locally. In all these cases, your git branch --contains <hash> would not find it. Try adding -a to include commits reachable from remote-tracking branches. Commented May 21, 2022 at 21:39
  • @RomainValeri git branch -a --contains <hash> returns nothing too... Commented May 22, 2022 at 1:01
  • These objects may not be reachable at all: the error occurs while trying to build the commit graph, during the process of painfully iterating over every object in the database to see whether they're reachable. The objects themselves are corrupted or missing. But as long as they're not actually used, that would be OK. Is this a partial clone? Commented May 22, 2022 at 4:14
  • @torek it is not a partial clone, it does not matter, just that i am having little bit OCD Commented May 24, 2022 at 13:36
  • Well, might be a good idea to make a backup clone of this clone "just in case" :-) Commented May 25, 2022 at 3:16

3 Answers 3

6

I got this error after changing history with git-repo-filter. Fixed this with the following command:

git commit-graph write --reachable
Sign up to request clarification or add additional context in comments.

Comments

0

I have fixed this with the following command:

docker exec -t GitLab git -C /var/opt/gitlab/git-data/repositories/@hashed/30/48/3148905660916d5dde3add79e63f095af3ffb81604691f21cad442a85c7be617.git commit-graph write

I use the Docker Omnibus version so your command might vary a bit. In the path after @hashed, you can find your repo path in the admin section of the GitLab project.

Comments

0

I had this problem too. Turned out that somehow I had two temp files ".tmp-xxxx-pack-xxxxxxxx..." lurking about in the .git/objects/pack directory. Try this at your own risk (I'd backup your entire source tree first TBH), but I deleted these .tmp-... files and retried git fsck - it worked perfectly.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.