Re: Database consistency after a successful pull
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Jun 6, 2005, 16:21 UTC
- Message-ID
- <Pine.LNX.4.21.0506061000531.30848-100000@iabervon.org>
- In-Reply-To
- <1118065849.8970.37.camel@jmcmullan.timesys>
On Mon, 6 Jun 2005, McMullan, Jason wrote:
Show 14 quoted lines
> 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*