Junio C Hamano wrote: >> $ ~/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. >> 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 :) >> 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"? >> 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? >> 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? >> 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?). > 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. >> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html