Ramkumar Ramachandra <artag...@gmail.com> writes:

> 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.

That is a trip in the kernel source, isn't it?  I cannot be your
guide there.

>>>   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"?

Another possibility is perhaps the objects that are referred to by
the index were missing or unreadable, and the index weren't.

>>>   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?

Explain why .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
was truncated to yourself, and the same explanation would apply to
the .git/logs/HEAD file, I think.

> This was mainly a learning exercise for me: I wanted to see how good
> git was at working with corrupted repositories.

You could have just asked ;-).

A tl;dr is that we _trust_ our refs and everything reachable from
them has to be complete.  If that is not the case, things will not
work, and it is not a priority to add workarounds in the normal
codepath to slow things down.

That does not forbid an addition of "git recover-corrupted-repo"
command, whose "assume everything might be broken" code is not
shared with the fastpath of other commands.

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

Reply via email to