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

Re: Why repository grows after "git gc"? / Purpose of *.keep files?

From
TLTeemu Likonen <tlikonen@iki.fi>
Date
May 13, 2008, 09:22 UTC
Message-ID
<20080513092237.GA4413@mithlond.arda.local>
In-Reply-To
<48292243.3050307@gnu.org>
Paolo Bonzini wrote (2008-05-13 07:08 +0200):
> I think separate cutoffs should be in place for file size and number
> of  objects.  Very tight packs probably require hours to repack as
> efficiently.
[...]
Show 5 quoted lines
> Thinking about both use cases, the best would be to have options
> (common  to git-clone, git-remote add, git-gc at least; and available
> via config  keys too) like
>
>   --keep-packs[=THRES1,THRES2,...]
Some thoughts from user interface's point of view. Two assumptions:
  - gc is daily or weekly operation
  - gc --aggressive is more like weekly or monthly operation.

In big repositories gc can feel pretty slow if there are not any .keep packs and user runs the command daily. So I think there's a point in having a .keep pack in repositories the size of linux-2.6 for example. But at the same time I think it would be nice to have an easy UI-way to repack with better disk space optimization.

This started as a crazy idea but maybe it's not so crazy so I'll rephrase my previous suggestion. At final stage the command gc --aggressive would add new .keep file which contains an identifier like

  This .keep file was added by "gc --aggressive" and
  will be automatically deleted at next run.
(Or something like that, you get the idea.)

At first gc --aggressive looks for .keep files with such identifier and deletes them if found. Then it proceeds normally and finally adds new .keep file with the same identifier.

This way the "daily" gc would operate very fast (as it leaves .keep packs alone), and with gc --aggressive user could easily decide when to create new landmark .keep packs (and also prune possible dangling objects inside previous .keep packs). Normal user don't need to know the details. Just run gc occasionally and maybe gc --aggressive when better optimization is needed.

How does this sound?
Previous: Shawn O. PearceNext: Stephen R. van den Berg
Message 33 of 35 in “Why repository grows after "git gc"? / Purpose of *.keep files?”
  1. Teemu LikonenMay 12, 2008
  2. Teemu LikonenMay 12, 2008
  3. Johannes SchindelinMay 12, 2008
  4. Teemu LikonenMay 12, 2008
  5. Nicolas PitreMay 12, 2008
  6. Teemu LikonenMay 12, 2008
  7. Nicolas PitreMay 12, 2008
  8. Govind SalinasMay 12, 2008
  9. Nicolas PitreMay 12, 2008
  10. Govind SalinasMay 12, 2008
  11. Teemu LikonenMay 12, 2008
  12. Mike HommeyMay 12, 2008
  13. Mike HommeyMay 12, 2008
  14. Shawn O. PearceMay 13, 2008
  15. Mike HommeyMay 13, 2008
  16. Nicolas PitreMay 14, 2008
  17. Junio C HamanoMay 14, 2008
  18. Juergen RuehleMay 14, 2008
  19. Nicolas PitreMay 14, 2008
  20. Junio C HamanoMay 14, 2008
  21. Linus TorvaldsMay 14, 2008
  22. Linus TorvaldsMay 14, 2008
  23. Nicolas PitreMay 14, 2008
  24. Linus TorvaldsMay 14, 2008
  25. A Large Angry SCMMay 14, 2008
  26. Nicolas PitreMay 12, 2008
  27. David TweedMay 12, 2008
  28. Shawn O. PearceMay 12, 2008
  29. Junio C HamanoMay 12, 2008
  30. Shawn O. PearceMay 13, 2008
  31. Paolo BonziniMay 13, 2008
  32. Shawn O. PearceMay 13, 2008
  33. Teemu LikonenMay 13, 2008
  34. Stephen R. van den BergMay 13, 2008
  35. Teemu LikonenMay 14, 2008

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.