Re: Database consistency after a successful pull

[Daniel Barkalow <barkalow@iabervon.org>]

On Mon, 6 Jun 2005, McMullan, Jason wrote:

> Subject Was: [PATCH] pull: gracefu[PAlly recover from delta retrieval
> failure.]
> 
> [snip lots of really good information about the thinking
>  behind the design of the pull mechanisms ]
> 
> Ok, so would I be correct in the following assumptions
> about the validity of a 'consistent' .git/objects database:
> 
> ============================================================
> 
> Commits:
> 	* May have the tree they refer to in the database
> 	* Must have their parents in the database

May have their parents in the database; we want to be able to drop ancient
history from non-archival sites at some point, if nothing else.

> Trees:
> 	* Must have the blobs they refer to in the database
> 	* Must have the trees they refer to in the database

It's probably true that there's no point to having a tree available if you
don't have its contents, although that's a convenient intermediate stage,
so that you can look up the contents of the tree with the ordinary parsing
code. On the other hand, I could imagine an ARM developer completely
ignoring arch/i386 (and just having write-tree use the parent tree's value
for it).

> Deltas:
> 	* Must have the referred to object in the database

Yes. Can't unpack without them.

> Blobs:
> 	* No references to check

Right.

Also, tags reference objects of unknown type; it's probably not vital to
have the object.

My bias is to call a database consistent with only deltas having the
referents; the rest goes towards completeness, since you have and can read
everything that you have anything for (but may not be able to do some
particular operation).

	-Daniel
*This .sig left intentionally blank*