Re: tree corrupted on disk quota full

On Thu, 11 Jan 2007, Michael S. Tsirkin wrote:

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

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.

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)

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