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

Re: [PATCH] gc --aggressive: make it really aggressive

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Dec 6, 2007, 16:19 UTC
Message-ID
<alpine.LFD.0.9999.0712060803430.13796@woody.linux-foundation.org>
In-Reply-To
<1196955059.13633.3.camel@brick>
On Thu, 6 Dec 2007, Harvey Harrison wrote:
> 
> 7:41:25elapsed 86%CPU

Heh. And this is why you want to do it exactly *once*, and then just export the end result for others ;)

> -r--r--r-- 1 hharrison hharrison 324094684 2007-12-06 07:26 pack-1d46ca030c3d6d6b95ad316deb922be06b167a3d.pack

But yeah, especially if you allow longer delta chains, the end result can be much smaller (and what makes the one-time repack more expensive is the window size, not the delta chain - you could make the delta chains longer with no cost overhead at packing time)

HOWEVER. 

The longer delta chains do make it potentially much more expensive to then use old history. So there's a trade-off. And quite frankly, a delta depth of 250 is likely going to cause overflows in the delta cache (which is only 256 entries in size *and* it's a hash, so it's going to start having hash conflicts long before hitting the 250 depth limit).

So when I said "--depth=250 --window=250", I chose those numbers more as an example of extremely aggressive packing, and I'm not at all sure that the end result is necessarily wonderfully usable. It's going to save disk space (and network bandwidth - the delta's will be re-used for the network protocol too!), but there are definitely downsides too, and using long delta chains may simply not be worth it in practice.

(And some of it might just want to have git tuning, ie if people think that long deltas are worth it, we could easily just expand on the delta hash, at the cost of some more memory used!)

That said, the good news is that working with *new* history will not be affected negatively, and if you want to be _really_ sneaky, there are ways to say "create a pack that contains the history up to a version one year ago, and be very aggressive about those old versions that we still want to have around, but do a separate pack for newer stuff using less aggressive parameters"

So this is something that can be tweaked, although we don't really have any really nice interfaces for stuff like that (ie the git delta cache size is hardcoded in the sources and cannot be set in the config file, and the "pack old history more aggressively" involves some manual scripting and knowing how "git pack-objects" works rather than any nice simple command line switch).

So the thing to take away from this is:
 - git is certainly flexible as hell
 - .. but to get the full power you may need to tweak things
 - .. happily you really only need to have one person to do the tweaking, 
   and the tweaked end results will be available to others that do not 
   need to know/care.

And whether the difference between 320MB and 500MB is worth any really involved tweaking (considering the potential downsides), I really don't know. Only testing will tell.

			Linus
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 57 of 89 in “Re: Git and GCC”
  1. David MillerDec 6, 2007
  2. Daniel BerlinDec 6, 2007
  3. David MillerDec 6, 2007
  4. Daniel BerlinDec 6, 2007
  5. David MillerDec 6, 2007
  6. Harvey HarrisonDec 6, 2007
  7. Daniel BerlinDec 6, 2007
  8. David MillerDec 6, 2007
  9. Daniel BerlinDec 6, 2007
  10. Harvey HarrisonDec 6, 2007
  11. Daniel BerlinDec 6, 2007
  12. Jon SmirlDec 6, 2007
  13. Jeff KingDec 6, 2007
  14. Nicolas PitreDec 6, 2007
  15. Jeff KingDec 6, 2007
  16. Nicolas PitreDec 6, 2007
  17. Jeff KingDec 7, 2007
  18. Jeff KingDec 7, 2007
  19. Linus TorvaldsDec 6, 2007
  20. Jon SmirlDec 6, 2007
  21. Nicolas PitreDec 6, 2007
  22. Jon SmirlDec 6, 2007
  23. Nicolas PitreDec 6, 2007
  24. Jon SmirlDec 6, 2007
  25. Jon SmirlDec 6, 2007
  26. Nicolas PitreDec 6, 2007
  27. Jon SmirlDec 6, 2007
  28. Jeff KingDec 7, 2007
  29. Harvey HarrisonDec 8, 2007
  30. Gabriel PaubertDec 10, 2007
  31. Nicolas PitreDec 10, 2007
  32. David MillerDec 7, 2007
  33. Jeff KingDec 7, 2007
  34. Jon SmirlDec 7, 2007
  35. David MillerDec 7, 2007
  36. Linus TorvaldsDec 7, 2007
  37. Giovanni BajoDec 7, 2007
  38. Jakub NarebskiDec 7, 2007
  39. Luke LuDec 7, 2007
  40. Giovanni BajoDec 7, 2007
  41. Daniel BerlinDec 7, 2007
  42. Johannes SchindelinDec 8, 2007
  43. David MillerDec 8, 2007
  44. David MillerDec 10, 2007
  45. Linus TorvaldsDec 6, 2007
  46. Harvey HarrisonDec 6, 2007
  47. David BrownDec 6, 2007
  48. Nicolas PitreDec 6, 2007
  49. gc --aggressive: make it really aggressiveJohannes Schindelin, Dec 6, 2007
  50. Theodore TsoDec 6, 2007
  51. Nicolas PitreDec 6, 2007
  52. Pierre HabouzitDec 6, 2007
  53. Johannes SchindelinDec 6, 2007
  54. David KastrupDec 6, 2007
  55. Harvey HarrisonDec 6, 2007
  56. Johannes SchindelinDec 6, 2007
  57. Linus TorvaldsDec 6, 2007
  58. Johannes SchindelinMar 18, 2009
  59. Teemu LikonenMar 18, 2009
  60. Nicolas PitreMar 18, 2009
  61. Daniel BerlinDec 6, 2007
  62. Linus TorvaldsDec 6, 2007
  63. Harvey HarrisonDec 7, 2007
  64. Linus TorvaldsDec 7, 2007
  65. Jon SmirlDec 7, 2007
  66. Nicolas PitreDec 7, 2007
  67. Linus TorvaldsDec 7, 2007
  68. Jon SmirlDec 7, 2007
  69. Nicolas PitreDec 7, 2007
  70. NightStrikeDec 6, 2007
  71. Linus TorvaldsDec 6, 2007
  72. NightStrikeDec 7, 2007
  73. Jon LoeligerDec 6, 2007
  74. Linus TorvaldsDec 6, 2007
  75. Jakub NarebskiDec 7, 2007
  76. Junio C HamanoDec 6, 2007
  77. Junio C HamanoDec 6, 2007
  78. David KastrupDec 6, 2007
  79. [OT] Re: Git and GCCRandy Dunlap, Dec 6, 2007
  80. Harvey HarrisonDec 6, 2007
  81. Linus TorvaldsDec 6, 2007
  82. Harvey HarrisonDec 6, 2007
  83. Johannes SchindelinDec 6, 2007
  84. Ismail DönmezDec 6, 2007
  85. "Argument list too long" in git remote update (Was: Git and GCC)Geert Bosch, Dec 17, 2007
  86. Johannes SchindelinDec 17, 2007
  87. Linus TorvaldsDec 17, 2007
  88. Derek FawcusDec 18, 2007
  89. Shawn O. PearceDec 18, 2007

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.