259

How often should you use git-gc?

The manual page simply says:

Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good operating performance.

Are there some commands to get some object counts to find out whether it's time to gc?

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
readonly
  • 343,444
  • 107
  • 203
  • 205
  • Tasks like these are prime candidates for cron (if you are using linux) http://minhajuddin.com/2011/12/09/gc-your-git-repositories-automatically-with-a-cron-task/ – Khaja Minhajuddin Dec 09 '11 at 07:11
  • 1
    Note: setting **`gc.autodetach`** (Git 2.0 Q2 2014) can help running `git gc --auto` without bloking the user. see [my answer below](http://stackoverflow.com/a/22358144/6309). – VonC Mar 12 '14 at 16:42

10 Answers10

226

It depends mostly on how much the repository is used. With one user checking in once a day and a branch/merge/etc operation once a week you probably don't need to run it more than once a year.

With several dozen developers working on several dozen projects each checking in 2-3 times a day, you might want to run it nightly.

It won't hurt to run it more frequently than needed, though.

What I'd do is run it now, then a week from now take a measurement of disk utilization, run it again, and measure disk utilization again. If it drops 5% in size, then run it once a week. If it drops more, then run it more frequently. If it drops less, then run it less frequently.

the Tin Man
  • 158,662
  • 42
  • 215
  • 303
Adam Davis
  • 91,931
  • 60
  • 264
  • 330
  • 21
    Manual says "Some git commands run git gc --auto after performing operations that could create many loose objects." Anyone know which commands actually run it? – Joshua Dance Jul 08 '14 at 15:36
  • 2
    A large git rebase is an obvious example, since many commits are rewritten into a new history - leaving lots of old commits in your repo which are part of the current branch anymore – mafrosis Nov 05 '14 at 06:11
  • 28
    "It won't hurt to run it more frequently than needed"... I don't entirely agree. As Aristotle points out, dangling commits can make a good backup mechanism. – Jason Baker Nov 22 '14 at 16:10
119

Note that the downside of garbage-collecting your repository is that, well, the garbage gets collected. As we all know as computer users, files we consider garbage right now might turn out to be very valuable three days in the future. The fact that git keeps most of its debris around has saved my bacon several times – by browsing all the dangling commits, I have recovered much work that I had accidentally canned.

So don’t be too much of a neat freak in your private clones. There’s little need for it.

OTOH, the value of data recoverability is questionable for repos used mainly as remotes, eg. the place all the devs push to and/or pulled from. There, it might be sensible to kick off a GC run and a repacking frequently.

Aristotle Pagaltzis
  • 112,955
  • 23
  • 98
  • 97
  • 45
    FWIW not all loose objects are garbage collected, only those older than 2 week by default (cf. `git gc --help`, specifically the `--prune` option). There is also mention of `gc.reflogExpire`, which leads me to believe that any commitish you've visited in the last 90 days will not be collected. (My git version: v1.7.6) – RobM Dec 06 '11 at 18:28
34

Recent versions of git run gc automatically when required, so you shouldn't have to do anything. See the Options section of man git-gc(1): "Some git commands run git gc --auto after performing operations that could create many loose objects."

mrowe
  • 841
  • 1
  • 7
  • 6
  • 21
    I just ran it for the first time on a several-year-old repository, and my .git went from 16M to 2.9M, an 82% reduction in size. It therefore still seems useful to manually run the command. – Darshan Rivka Whittle Apr 16 '15 at 22:00
  • @DarshanRivkaWhittle had you updated git in those several years? – std''OrgnlDave Apr 03 '19 at 19:57
  • 4
    @std''OrgnlDave Yeah, I was always running whatever version was current on Arch. I just ran it again, maybe for the first time since my last comment (thanks to your comment reminding me), and my .git went from 81M to 13M. I must not run any of the commands that run `gc --auto`, I guess. – Darshan Rivka Whittle Apr 03 '19 at 20:46
21

If you're using Git-Gui, it tells you when you should worry:

This repository currently has approximately 1500 loose objects.

The following command will bring a similar number:

$ git count-objects

Except, from its source, git-gui will do the math by itself, actually counting something at .git/objects folder and probably brings an approximation (I don't know tcl to properly read that!).

In any case, it seems to give the warning based on an arbitrary number around 300 loose objects.

Community
  • 1
  • 1
cregox
  • 17,674
  • 15
  • 85
  • 116
  • Indeed it does warn, but upon letting it run gc, most of the time gc wont do a thing. So relying on git gui to do it, is to wait for more than 6000something loose objects with always having to click on either run gc and wait for a minute or cancel :/ Probably someone should fix git gui in a way that it checks max loose object count and not bother to show the dialog until the count reaches the limit. – mlatu Feb 13 '14 at 10:30
  • Yes @mlatu I agree. When I wrote this I just wanted to bring attention to it. Both `Git-Gui` and `count-objects` are not exactly good answers to the question here... But they should be! – cregox Feb 13 '14 at 11:05
  • i didnt mean that this is a bad answer, just wanted to point out that most of the time git gui does nothing. though i suppose git gc doesnt do much either, except when there is enough to do or you used the aggressive switch. – mlatu Feb 13 '14 at 13:47
8

You can do it without any interruption, with the new (Git 2.0 Q2 2014) setting gc.autodetach.

See commit 4c4ac4d and commit 9f673f9 (Nguyễn Thái Ngọc Duy, aka pclouds):

gc --auto takes time and can block the user temporarily (but not any less annoyingly).
Make it run in background on systems that support it.
The only thing lost with running in background is printouts. But gc output is not really interesting.
You can keep it in foreground by changing gc.autodetach.

Since that 2.0 release, there was a bug though: git 2.7 (Q4 2015) will make sure to not lose the error message.
See commit 329e6e8 (19 Sep 2015) by Nguyễn Thái Ngọc Duy (pclouds).
(Merged by Junio C Hamano -- gitster -- in commit 076c827, 15 Oct 2015)

gc: save log from daemonized gc --auto and print it next time

While commit 9f673f9 (gc: config option for running --auto in background - 2014-02-08) helps reduce some complaints about 'gc --auto' hogging the terminal, it creates another set of problems.

The latest in this set is, as the result of daemonizing, stderr is closed and all warnings are lost. This warning at the end of cmd_gc() is particularly important because it tells the user how to avoid "gc --auto" running repeatedly.
Because stderr is closed, the user does not know, naturally they complain about 'gc --auto' wasting CPU.

Daemonized gc now saves stderr to $GIT_DIR/gc.log.
Following gc --auto will not run and gc.log printed out until the user removes gc.log.

zb226
  • 9,586
  • 6
  • 49
  • 79
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
8

Drop it in a cron job that runs every night (afternoon?) when you're sleeping.

Pat Notz
  • 208,672
  • 30
  • 90
  • 92
7

This quote is taken from; Version Control with Git

Git runs garbage collection automatically:

• If there are too many loose objects in the repository

• When a push to a remote repository happens

• After some commands that might introduce many loose objects

• When some commands such as git reflog expire explicitly request it

And finally, garbage collection occurs when you explicitly request it using the git gc command. But when should that be? There’s no solid answer to this question, but there is some good advice and best practice.

You should consider running git gc manually in a few situations:

• If you have just completed a git filter-branch . Recall that filter-branch rewrites many commits, introduces new ones, and leaves the old ones on a ref that should be removed when you are satisfied with the results. All those dead objects (that are no longer referenced since you just removed the one ref pointing to them) should be removed via garbage collection.

• After some commands that might introduce many loose objects. This might be a large rebase effort, for example.

And on the flip side, when should you be wary of garbage collection?

• If there are orphaned refs that you might want to recover

• In the context of git rerere and you do not need to save the resolutions forever

• In the context of only tags and branches being sufficient to cause Git to retain a commit permanently

• In the context of FETCH_HEAD retrievals (URL-direct retrievals via git fetch ) because they are immediately subject to garbage collection

Community
  • 1
  • 1
Teoman shipahi
  • 47,454
  • 15
  • 134
  • 158
  • 2
    I have unreachable commits in my tree (as a result of `git commit --amend`). This can be verified with `git log --reflog`. I pushed a branch to the remote repository and checked my tree again; the unreachable commits were still there. Apparently `git gc` was not run when this push happened. … ? – chharvey Feb 27 '16 at 04:33
  • From https://www.atlassian.com/git/tutorials/git-gc:`gc.reflogExpire`: `An optional variable that defaults to 90 days. It is used to set how long records in a branches reflog should be preserved.` – TheTechRobo the Nerd Nov 29 '21 at 23:04
7

I use git gc after I do a big checkout, and have a lot of new object. it can save space. E.g. if you checkout a big SVN project using git-svn, and do a git gc, you typically save a lot of space

Amandasaurus
  • 58,203
  • 71
  • 188
  • 248
  • Is this still true? Even in '08 HDD space was cheap, using that as a justification to run it seems pointless – Thymine Jul 20 '18 at 21:43
4

I use when I do a big commit, above all when I remove more files from the repository.. after, the commits are faster

ghiboz
  • 7,863
  • 21
  • 85
  • 131
3

You don't have to use git gc very often, because git gc (Garbage collection) is run automatically on several frequently used commands:

git pull
git merge
git rebase
git commit

Source: git gc best practices and FAQS

Immi
  • 127
  • 7