Home/ Questions/Q 7520227
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T02:01:54+00:00

I’m debugging a case of git repository corruption, caused by a hard drive failure.

  • 0

I’m debugging a case of git repository corruption, caused by a hard drive failure. I have

>git fsck --full
fatal: loose object 25e9d8d2deb964c3da0f86f60bbd5a23e8387349 (stored in
.git/objects/25/e9d8d2deb964c3da0f86f60bbd5a23e8387349) is corrupt

>git show 25e9d8d2deb964c3da0f86f60bbd5a23e8387349
fatal: loose object 25e9d8d2deb964c3da0f86f60bbd5a23e8387349 (stored in
.git/objects/25/e9d8d2deb964c3da0f86f60bbd5a23e8387349) is corrupt

Now, I’d like to know something about this object – what it is, where does it belong ? (Which folder, which commit?)

When I try to investigate the object its stored in, I get:

>git show e9d8d2deb964c3da0f86f60bbd5a23e8387349
fatal: ambiguous argument 'e9d8d2deb964c3da0f86f60bbd5a23e8387349': unknown revision or
path not in the working tree. Use '--' to separate paths from revisions

How should I proceed?

I have a copy of the repository from earlier today, but I wouldn’t want to just trash my local changes – I would prefer to see if I can fix the repo, or perhaps just trash a single commit.

P.S. – I found several threads about the “loose objects” problem, but nothing with concrete instructions on how to investigate/resolve, both in case where I do find a backup of the corrupt object in another repo, and in the case where there is no backup of this object.

P.S. 2 – Oddly enough, gitk --all works well and doesn’t care about this corrupt state.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The message “loose object 25e9d8d2deb964c3da0f86f60bbd5a23e8387349” tells you already the exact hash of said object; it’s 25e9d8d2deb964c3da0f86f60bbd5a23e8387349. Git just organizes objects in subdirectories by splitting off the first two characters for a separate directory. So that object is stored in /25/e9d8d2deb964c3da0f86f60bbd5a23e8387349, but that doesn’t change that its identifier is the full hash.

    As such you would only need to use git show 25e9d8d2deb964c3da0f86f60bbd5a23e8387349. This however fails as the object is corrupt, so there is no real way to restore it.

    The good message however is that “loose object” means that nothing is pointing on it, so if your repository is otherwise fine, you will not need that object.

    Oddly enough, gitk –all works well and doesn’t care about this corrupt state.

    gitk – as well as nearly all other user commands from Git – only look at the objects reachable from HEAD or another named reference (branches, tags). So if there is a loose object, nothing is pointing at it, as such especially neither HEAD nor another named reference is pointing at it, and no error appears.

    • 0