I think that git-recover-repository is ready now. Made it deal with the index file referencing corrupt objects. The best approach I could think of for that is to just remove those objects from the index, so the user can re-add files from their work tree after recovery.
Now to integrate this git repository repair capability into the git-annex
assistant. I decided to run git fsck as part of a scheduled
repository consistency check. It may also make sense for the assistant to
notice when things are going wrong, and suggest an immediate check. I've
started on the webapp UI to run a repository repair when fsck detects
problems.
Awesome that you're working on recovery, and recovery automation!
Please only bother the user if there is a serious problem and it can't be fixed without their help. Otherwise I fear people will learn to ignore your dialog boxes, like they do most dialog boxes. If you want to notify your user that some hard drive corruption happened (and it's been fixed already) then put a little yellow/orange line across somewhere with a warning message.
When I read to the part about how it can (probably) be fixed automatically, I got a flash of annoyance and thought "well, then fix it automatically, why are you bothering me?"
Please (if you aren't already) check if it can be automatically fixed without help from the user before telling the user about it. Then you can say "The data to fix this could not be reached, please plug in another repo or something."