Dear diary, on Fri, Apr 22, 2005 at 09:46:35PM CEST, I got a letter where Daniel Barkalow <[EMAIL PROTECTED]> told me that... > On Thu, 21 Apr 2005 [EMAIL PROTECTED] wrote: > > > On Wed, 20 Apr 2005, Brad Roberts wrote: > > > How about fetching in the inverse order. Ie, deepest parents up towards > > > current. With that method the repository is always self consistent, even > > > if not yet current. > > > > Daniel Barkalow replied: > > > You don't know the deepest parents to fetch until you've read everything > > > more recent, since the history you'd have to walk is the history you're > > > downloading. > > > > You "just" need to defer adding tree/commit objects to the repository until > > after you have inserted all objects on which they depend. That's what my > > "wget" based version does ... it's very crude, in that it loads all tree > > & commit objects into a temporary repository (.gittmp) ... since you can > > only use "cat-file" and "ls-tree" on things if they live in > > objects/xx/xxx..xxx > > The blobs can go directly into the real repo (but to be really safe you'd > > have to ensure that the whole blob had been pulled from the network before > > inserting it ... it's probably a good move to validate everything that you > > pull from the outside world too). > > The problem with this general scheme is that it means that you have to > start over if something goes wrong, rather than resuming from where you > left off (and being able to use what you got until then).
Huh. Why? You just go back to history until you find a commit you already have. If you did it the way as Tony described, if you have that commit, you can be sure that you have everything it depends on too. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html