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

Re: git pull & git gc

From
Jeff King <peff@peff.net>
Date
Mar 19, 2015, 04:20 UTC
Message-ID
<20150319042050.GA29999@peff.net>
In-Reply-To
<CACsJy8CUbe4-f4rpieAKYzHb4rpKg8JW+uXB5yA4c1HFG6r4dg@mail.gmail.com>
On Thu, Mar 19, 2015 at 11:15:19AM +0700, Duy Nguyen wrote:
Show 14 quoted lines
> On Thu, Mar 19, 2015 at 8:27 AM, Jeff King <peff@peff.net> wrote:
> > Keeping a file that says "I ran gc at time T, and there were still N
> > objects left over" is probably the best bet. When the next "gc --auto"
> > runs, if T is recent enough, subtract N from the estimated number of
> > objects. I'm not sure of the right value for "recent enough" there,
> > though. If it is too far back, you will not gc when you could. If it is
> > too close, then you will end up running gc repeatedly, waiting for those
> > objects to leave the expiration window.
> 
> And would not be hard to implement either. git-gc is already prepared
> to deal with stale gc.pid, which would stop git-gc for a day or so
> before it deletes gc.pid and starts anyway. All we need to do is check
> at the end of git-gc, if we know for sure the next 'gc --auto' is a
> waste, then leave gc.pid behind.

That omits the "N objects left over" information. Which I think may be useful, because otherwise the rule is basically "don't do another gc at all for X time units". That's OK for most use, but it has its own corner cases. E.g., imagine you are doing an SVN import that does an auto-gc check every 1000 commits. You have some unreferenced objects in your repository. After the first 1000 commits, we do a gc, and then say "wow, still a lot of cruft; let's block gc for a day". Five minutes later, after another 1000 commits, we run "gc --auto" again. It doesn't run because of the cruft-check, even though there are a _huge_ number of new packable objects.

If the blocker file tells us "7000 extra objects" and we see that there are 17,000 in the repo, then we know it's still worth doing the gc (i.e., we know we that we'll probably end up ignoring the 7000 cruft that didn't get cleaned up last time, but we also know that there are 10,000 new objects).

-Peff
Previous: Duy NguyenNext: Duy Nguyen
Message 16 of 21 in “git pull & git gc”
  1. Дилян ПалаузовMar 18, 2015
  2. Duy NguyenMar 18, 2015
  3. Дилян ПалаузовMar 18, 2015
  4. Duy NguyenMar 18, 2015
  5. Duy NguyenMar 18, 2015
  6. John KeepingMar 18, 2015
  7. Jeff KingMar 18, 2015
  8. Duy NguyenMar 19, 2015
  9. Jeff KingMar 19, 2015
  10. Mike HommeyMar 19, 2015
  11. Jeff KingMar 19, 2015
  12. Mike HommeyMar 19, 2015
  13. Junio C HamanoMar 19, 2015
  14. Jeff KingMar 19, 2015
  15. Duy NguyenMar 19, 2015
  16. Jeff KingMar 19, 2015
  17. Duy NguyenMar 19, 2015
  18. Jeff KingMar 19, 2015
  19. Duy NguyenMar 19, 2015
  20. Дилян ПалаузовMar 18, 2015
  21. Jeff KingMar 18, 2015

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.