Re: [PATCH] pull: gracefully recover from delta retrieval failure.

[Jason McMullan <jason.mcmullan@timesys.com>]

On Sat, 2005-06-04 at 23:11 -0700, Junio C Hamano wrote:
> This addresses a concern raised by Jason McMullan in the mailing
> list discussion.  After retrieving and storing a potentially
> deltified object, pull logic tries to check and fulfil its delta
> dependency.  When the pull procedure is killed at this point,
> however, there was no easy way to recover by re-running pull,
> since next run would have found that we already have that
> deltified object and happily reported success, without really
> checking its delta dependency is satisfied.

I still think it would be much better if you didn't place unverified
objects in the database in the first place. You've taken care of delta
object recovery, yes, but what about unsatisfied tree objects? Or commit
objects? Does your algorithm require full depth scanning of the
entire repository that is descended from the commit head?

I much prefer to always leave the database in a consistent state, that
way you only have to do O(number-of-retrieved-objects) verifications,
not O(number-of-commit-tree-ancestors) verifications.

Or am I misunderstanding your technique here? 

Sorry about being a pest, but this worries me. Please assuage my fears.

(Or, if you'd like, I can rework pull.c to use the
 verification-before-store technique I used in my git-daemon patch, so
 all the *-pull mechanisms will be 'safe')