Re: Database consistency after a successful pull

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*