On Thu, 11 Jan 2007, Michael S. Tsirkin wrote: > > I did lots of resets and they did not seems to help. NOTE! If "nothing seems to help" means "git-fsck-objects" still complains, then that is very much expected. "git reset" does NOT fix a corrupted database. Never has, never will. It should only fix the case where a branch head points to a corrupt or incomplete tree. To actually fix the database, you need to remove the broken objects. Which "git prune" did for you (but you could have just done it by hand too). > Then, on a hunch, I just did git prune and > it cleaned the tree so I can pull/push fine. If so, your branch heads had _already_ been fixed (by one of the resets), and "git prune" just got rid of the (unreachable) objects that were broken. > How come? What happens is: - you had gotten some corrupt objects due to the disk filling up (probably during the pull that thus populated the object database with partially written objects) In particular, the 4d4d30be967d3284cbf59afd4fba6ab536e295f5 object was corrupt. fsck gave a confusing error message: error: 4d4d30be967d3284cbf59afd4fba6ab536e295f5: object not found error: c03590b581d51d5fa43adbef9415e935d0229412: object not found which is really because the _file_ for that object does exist, but the file doesn't actually contain the object it expects (due to corruption), so the object wasn't "found". - git-fsck-objects complained about them, but it doesn't actually do anything about it (which you maybe expected it to do - it doesn't really act as a filesystem fsck which tries to _fix_ things, it really just does the "check" part, since "fixing" things is almost always a manual operation) - "git prune" actually removed all the unreachable objects, and since none of the _reachable_ objects were broken, that makes git-fsck-objects shut up too. - your "git pull" failed, because it was fetching objects that were corrupt in your local database - and the rule is that local objects ALWAYS override remote objects. That's an important security thing (a "pull" is _never_ allowed to overwrite something you already have, and it doesn't matter if it's corrupt or not, you're not ever going to have a "git pull" overwriting old data) > So it seems the tree was more or less fine (it just has some useless objects > because of the disk full failure), the bug seems to be that pull/push fail. Not a bug. See above. It's really a very important safety feature: we never EVER overwrite any old objects. Even if they are corrupt. But it means that you need to _fix_ any corruption in order to use the repository. That's a security feature. It's a feature because git absolutely ALWAYS considers the "local repository" to be the trustworthy one. It matters not a whit if git thinks a local object may be corrupt - the local copy is _still_ considered to always be the definite copy. It's part of what makes git stable. You may not think that sounds "stable" to you right now, in that it made it harder to "fix" the problem, but it indirectly means that even a _buggy_ git binary (say, you by mistake use an older git binary that doesn't understand some new object format) will never overwrite data that you already had. That's true safety. It does mean that if you have a corrupt database, you really do need to fix it first, but it's _still_ a safety feature: git won't fix the database for you "by mistake". You need to fix it consciously. That's true robustness. Linus - 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