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

Re: Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack file

From
Shawn O. Pearce <spearce@spearce.org>
Date
Jan 8, 2009, 01:46 UTC
Message-ID
<20090108014646.GD10790@spearce.org>
In-Reply-To
<alpine.LFD.2.00.0901071726020.3283@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 16 quoted lines
> On Wed, 7 Jan 2009, Linus Torvalds wrote:
> > 
> > So there's a few rules to packedgitwindowsize:
> > 
> >  - we need to be able to have at least two windows open at a time, in 
> >    addition to all the "normal" memory git needs just for objects, of 
> >    course. And quite frankly, you'd be better off with a few more windows, 
> >    even if that obviously implies smaller windows.
> 
> Btw, I'm not 100% certain of this. Somebody should double-check me. Maybe 
> there are cases where we want more than two windows alive. And maybe there 
> aren't even that, and we can always make do with just one.
> 
> So I will _not_ guarantee that "at least two pack windows" is necessarily 
> the right answer. The windowing code was mostly other people doing it. I 
> think Shawn and Nico.

I was fairly certain we needed at least two windows open at once, but reviewing the code in sha1_file.c I don't see a reason for that restriction anymore.

I think it used to have to do with the delta reconstruction; to unpack a delta we would read the delta header from one window, but we may need base data from another. The delta unpack code kept the delta window pinned in use, so we couldn't replace it to access base data from elsewhere, hence we needed two windows. Thinking about it now I don't recall how we handled the recusion on a delta chain longer than 2. ;-)

But looking at the code we have long since refactored it so this isn't an issue anymore. We release the window between reading the delta header and reading the base, so the delta window can be replaced if necessary. I think the "2 window minimum" is just a performance suggestion, not a requirement.

-- 
Shawn.
Previous: Linus TorvaldsNext: James Pickens
Message 26 of 49 in “Allow writing loose objects that are corrupted in a pack file”
  1. Allow writing loose objects that are corrupted in a pack fileJan Krüger, Dec 9, 2008
  2. R. Tyler BallanceDec 9, 2008
  3. Shawn O. PearceDec 9, 2008
  4. R. Tyler BallanceJan 6, 2009
  5. Nicolas PitreJan 7, 2009
  6. R. Tyler BallanceJan 7, 2009
  7. Nicolas PitreJan 7, 2009
  8. R. Tyler BallanceJan 7, 2009
  9. Nicolas PitreJan 7, 2009
  10. Linus TorvaldsJan 7, 2009
  11. R. Tyler BallanceJan 7, 2009
  12. Junio C HamanoJan 7, 2009
  13. R. Tyler BallanceJan 7, 2009
  14. Junio C HamanoJan 7, 2009
  15. R. Tyler BallanceJan 7, 2009
  16. Nicolas PitreJan 7, 2009
  17. Linus TorvaldsJan 7, 2009
  18. Linus TorvaldsJan 7, 2009
  19. R. Tyler BallanceJan 7, 2009
  20. Linus TorvaldsJan 7, 2009
  21. Public repro case! Re: [PATCH/RFC] Allow writing loose objects that are corrupted in a pack fileR. Tyler Ballance, Jan 8, 2009
  22. Linus TorvaldsJan 8, 2009
  23. R. Tyler BallanceJan 8, 2009
  24. Linus TorvaldsJan 8, 2009
  25. Linus TorvaldsJan 8, 2009
  26. Shawn O. PearceJan 8, 2009
  27. James PickensJan 8, 2009
  28. Shawn O. PearceJan 8, 2009
  29. Junio C HamanoJan 8, 2009
  30. Shawn O. PearceJan 8, 2009
  31. Boyd Stephen Smith Jr.Jan 8, 2009
  32. Linus TorvaldsJan 8, 2009
  33. Shawn O. PearceJan 8, 2009
  34. Linus TorvaldsJan 8, 2009
  35. Shawn O. PearceJan 8, 2009
  36. Wrap inflateInit to retry allocation after releasing pack memoryShawn O. Pearce, Jan 8, 2009
  37. Linus TorvaldsJan 8, 2009
  38. Junio C HamanoJan 8, 2009
  39. Linus TorvaldsJan 8, 2009
  40. Shawn O. PearceJan 8, 2009
  41. Linus TorvaldsJan 8, 2009
  42. R. Tyler BallanceJan 8, 2009
  43. Linus TorvaldsJan 8, 2009
  44. R. Tyler BallanceJan 8, 2009
  45. Junio C HamanoJan 9, 2009
  46. Linus TorvaldsJan 8, 2009
  47. R. Tyler BallanceJan 8, 2009
  48. Linus TorvaldsJan 8, 2009
  49. R. Tyler BallanceJan 8, 2009

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.