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

Re: [PATCH] git exproll: steps to tackle gc aggression

From
Jeff King <peff@peff.net>
Date
Aug 10, 2013, 09:50 UTC
Message-ID
<20130810095000.GC2518@sigill.intra.peff.net>
In-Reply-To
<CACsJy8BZv0nr92foiYpbscpg86awFZVerpeXcz5CuYWeg3guEA@mail.gmail.com>
On Sat, Aug 10, 2013 at 08:24:39AM +0700, Nguyen Thai Ngoc Duy wrote:
Show 13 quoted lines
> > the other end cannot use). You _might_ be able to get by with a kind of
> > "two-level" hack: consider your main pack as "group A" and newly pushed
> > packs as "group B". Allow storing thin deltas on disk from group B
> > against group A, but never the reverse (nor within group B). That makes
> > sure you don't have cycles, and it eliminates even more I/O than any
> > repacking solution (because you never write the extra copy of Y to disk
> > in the first place). But I can think of two problems:
> [...]
> 
> Some refinements on this idea
> 
>  - We could keep packs in group B ordered as the packs come in. The
> new pack can depend on the previous ones.

I think you could dispense with the two-level altogether and simply give a definite ordering to packs, whereby newer packs can only depend on older packs. Enforcing that with filesystem mtime feels a bit error-prone; I think you'd want to explicitly store a counter somewhere.

>  - A group index in addition to separate index for each pack would
> solve linear search object lookup problem.

Yeah. I do not even think it would be that much work. It is a pure optimization, so you can ignore issues like "what happens if I search for an object, but the pack it is supposed to be in went away?". The answer is "you fall back to a linear search through the packs", and assume it happens infrequently enough not to care.

I'd wait to see how other proposed optimizations work out before doing a global index, though. The current wisdom is "don't have a ton of packs, for both the index issue and other reasons, like wasting space and on-the-fly deltas for fetches". If the "other reasons" go away, then a global index would make sense to solve the remaining issue. But if the solution for the other issues is to make it cheaper to repack so you can do it more often, then the index issue just goes away.

-Peff
Previous: Duy NguyenNext: Junio C Hamano
Message 20 of 33 in “git exproll: steps to tackle gc aggression”
  1. git exproll: steps to tackle gc aggressionRamkumar Ramachandra, Aug 6, 2013
  2. Duy NguyenAug 6, 2013
  3. Junio C HamanoAug 6, 2013
  4. Ramkumar RamachandraAug 7, 2013
  5. Junio C HamanoAug 8, 2013
  6. Ramkumar RamachandraAug 8, 2013
  7. Junio C HamanoAug 8, 2013
  8. Martin FickAug 8, 2013
  9. Junio C HamanoAug 8, 2013
  10. Ramkumar RamachandraAug 8, 2013
  11. Ramkumar RamachandraAug 8, 2013
  12. Junio C HamanoAug 8, 2013
  13. Ramkumar RamachandraAug 8, 2013
  14. Martin LanghoffAug 8, 2013
  15. Jeff KingAug 9, 2013
  16. Ramkumar RamachandraAug 9, 2013
  17. Junio C HamanoAug 9, 2013
  18. Jeff KingAug 9, 2013
  19. Duy NguyenAug 10, 2013
  20. Jeff KingAug 10, 2013
  21. Junio C HamanoAug 10, 2013
  22. Ramkumar RamachandraAug 10, 2013
  23. Duy NguyenAug 10, 2013
  24. Duy NguyenAug 10, 2013
  25. Jeff KingAug 10, 2013
  26. Duy NguyenAug 10, 2013
  27. Ramkumar RamachandraAug 10, 2013
  28. Duy NguyenAug 10, 2013
  29. Jeff KingAug 10, 2013
  30. Martin FickAug 7, 2013
  31. Duy NguyenAug 8, 2013
  32. Martin FickAug 7, 2013
  33. Ramkumar RamachandraAug 7, 2013

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.