Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html