Re: [HELP] Corrupted repository
- From
Ramkumar Ramachandra <artagnon@gmail.com>
- Date
- Jun 21, 2013, 16:44 UTC
- Message-ID
- <CALkWK0mTZqtGFp-BW9XBjX4Cm2hCZ1=P5M0a4cMBuE0v__LpZw@mail.gmail.com>
- In-Reply-To
- <7v7ghno2lz.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 10 quoted lines
>> $ ~/src/git >> error: object file >> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty >> error: object file >> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty >> fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored >> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt > > So fsync() and close() thought that the filesystem stored this loose > object safely, but it turns out that the data is not on disk.
Where should I start digging if I want to fix this? Actually you just need to tell me how to build reduced-case corruptions to test: I can trace and figure out the rest.
Show 6 quoted lines
>> artagnon|remote-cruft*+:~/src/git$ git prune >> artagnon|remote-cruft*+:~/src/git$ git status >> fatal: bad object HEAD >> fatal: bad object HEAD > > And the value in the HEAD was???
ref: refs/heads/remote-cruft. That's why I included my prompt :)
Show 16 quoted lines
>> artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master >> artagnon|master*+=:~/src/git$ git status >> ## master >> MM Documentation/git-ls-remote.txt >> MM remote.c >> MM t/t5505-remote.sh >> MM t/t5510-fetch.sh >> MM t/t5515-fetch-merge-logic.sh >> MM t/t5516-fetch-push.sh >> ?? lib/ >> ?? outgoing/ >> >> That status is completely bogus, by the way. > > ... which may suggest that your index file may have been corrupted > on the filesystem.
Yeah, my question pertains to why is the index half-corrupted. Is there no checksum to say "index corrupted; do not display bogus nonsense"?
Show 11 quoted lines
>> artagnon|master*+=:~/src/git$ git checkout remote-cruft
>> fatal: reference is not a tree: remote-cruft
>> artagnon|master=:~/src/git$ git reflog
>> 21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
>> refs/heads/remote-cruft
>>
>> What happened to the rest of my reflog?!
>
> On the filesystem known to not record the last consistent state of
> the repository, the answer to that question may be rather obvious,
> no?I didn't understand. What does .git/logs/HEAD have to do with any of this? Why is it truncated?
Show 6 quoted lines
>> artagnon|master=:~/src/git$ git branch -D remote-cruft >> error: Couldn't look up commit object for 'refs/heads/remote-cruft' > > The command would want to report what was at the tip, so it is > understandable it may want to look up that commit before removing > the ref.
I would have expected it to display a warning and remove the ref anyway. Or error out, and override with a force-flag?
Show 11 quoted lines
>> Fine, let's fetch. > > Why? > > "fetch" walks the ancestry graph on both ends to minimize transfers. > It's not something you would expect to work when you know refs at > your end does not even record what you do have. It _may_ appear to > work if your refs are intact but you are missing objects, as they > will not be transferred again from the good copy if you let your > repository's ref claim that you have _all_ objects behind it when > you actually don't.
Right. I expected it to figure out that I have a broken history and fetch everything (which is what happened the second time, no?).
Show 5 quoted lines
> What would have been a better starting point to untangle is to make > a separate clone, pretending as if this repository did not even > exist, and copy the resulting packfile into this repository. That > would at least give you a known good copies of objects that you > already have pushed out.
Yeah, I deliberately avoided doing that: apart from the config and refs, I had no real unpushed work in ~/src/git anyway (I push _very_ frequently, which explains my "resolve HEAD early in current" patch). The most important part of what I did was running unpack-objects by hand: that fixed everything. I shouldn't have had to run that by hand though: why isn't there an in-built way to unpack everything, remove corruptions, and repack the good stuff?
> And the next step would have been (without doing any of the above > "remove this branch, recreate this one anew") to compare the tips > of refs in this broken repository and the clone. The same ones you > can trust, and different ones you dig further.
Right. I didn't have local data in this case, so I didn't bother.
Show 5 quoted lines
>> Was I being stupid, or is fixing corrupted repositories really this >> non-trivial? Comments appreciated. > > I think "Let's fetch first" was the step that took you in a wrong > direction that requires unnecessary work.
This was mainly a learning exercise for me: I wanted to see how good git was at working with corrupted repositories. I did my surgery fairly quickly, and avoided large network transfers (I have a slow connection).