git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
JMJason McMullan <jason.mcmullan@timesys.com>
Date
Jun 5, 2005, 16:38 UTC
Message-ID
<1117989532.10424.7.camel@port.evillabs.net>
In-Reply-To
<7v4qcde3j9.fsf@assigned-by-dhcp.cox.net>
On Sat, 2005-06-04 at 23:11 -0700, Junio C Hamano wrote:
Show 8 quoted lines
> 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')
Previous: Junio C HamanoNext: Daniel Barkalow
Message 2 of 8 in “pull: gracefully recover from delta retrieval failure.”
  1. pull: gracefully recover from delta retrieval failure.Junio C Hamano, Jun 5, 2005
  2. Jason McMullanJun 5, 2005
  3. Daniel BarkalowJun 5, 2005
  4. Junio C HamanoJun 5, 2005
  5. Daniel BarkalowJun 5, 2005
  6. Database consistency after a successful pullMcMullan, Jason, Jun 6, 2005
  7. Daniel BarkalowJun 6, 2005
  8. McMullan, JasonJun 6, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.