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

On Sun, 5 Jun 2005, Jason McMullan wrote:

(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')

The reasons I don't really want a verification-before-store are:

 - I'd like things to be resumable on error; if you've already got a bunch
   of stuff and then the connection breaks, you should already have the
   things you got; so, at least, the temporary locations should be
   something predictable from the hash.

 - I'd like the user to be able to intentionally get partial repositories
   of various sorts, and still have consistant information. If I don't
   have anything written that's not in mainline, and I'm not going to be
   applying other people's patches, and I don't have an up-to-date
   repository, I'd like to be able to pull just mainline's head commit and
   tree, and work from there. I don't need the history unless I want to
   look up changes or want to merge something that's not derived entirely
   from the head I've got.

So what I'd really like is something where you store whatever objects you
have, and also have extra information about what objects you know about
but don't have and what objects you've gotten completely. Of course, this
needs to be kept manageable.

(Along the lines of the second one, there's a variety of partial
information which is sufficient for various purposes. If I trust that
Linus's latest tree is based on my most recent pull from him, I can
fast-forward with just the tree. I can also merge his tree into mine with
just the commits and his latest tree, since I must already have any common
ancestors. In all these cases, I may want to streamline my process by
doing "pull tree; pull all &; checkout" or 
"pull tree,commits; pull all &; merge", so that I can start on further
development while the rest of the information fills in.)

So I'd greatly prefer to keep the metadata of what objects we have
explicitly, rather than implicitly in the presence or absence of files in
the object directory. Also, for objects which we expect to be missing, it
would be good to keep info on where we expect to be able to get
them. Then, if I'm wrong about what I actually needed, it doesn't need me
to tell it again where to get things.

	-Daniel
*This .sig left intentionally blank*