146

When I run 'git gui' I get a popup that says

This repository currently has approximately 1500 loose objects.

It then suggests compressing the database. I've done this before, and it reduces the loose objects to about 250, but that doesn't suppress the popup. Compressing again doesn't change the number of loose objects.

Our current workflow requires significant use of 'rebase' as we are transitioning from Perforce, and Perforce is still the canonical SCM. Once Git is the canonical SCM, we will do regular merges, and the loose objects problem should be greatly mitigated.

In the mean time, I'd really like to make this 'helpful' popup go away.

JJD
  • 50,076
  • 60
  • 203
  • 339
Michael Donohue
  • 11,776
  • 5
  • 31
  • 44
  • 4
    That dialog is a great example of a "feature" that many people would wish it didn't exist. It is not only annoying, it can erase important commits that became detached after a hard reset. – adelriosantiago Sep 05 '17 at 03:25

5 Answers5

202

Since nobody had yet an answer, I looked into the code to see how to remove the code which shows up that dialog. I found the hint_gc procedure which does it and the place where it is called. At the same time I noticed that late 2011 there was added a configuration option for disabling the dialog. This change (part of git-gui 0.16.0) was merged to Git's mainline on 2011-12-14.

So if you use Git v1.7.9 or newer, you can disable the warning dialog with the following command:

git config --global gui.gcwarning false

If you are using an older version, then you can edit /lib/git-core/git-gui and remove the after 1000 hint_gc line, or edit /usr/share/git-gui/lib/database.tcl and remove the body of the hint_gc procedure. (These file paths are on Cygwin - on other environments the files might be in a different locations. For Windows it is c:\Program Files\Git\mingw64\libexec\git-core\git-gui.tcl)

sashoalm
  • 75,001
  • 122
  • 434
  • 781
Esko Luontola
  • 73,184
  • 17
  • 117
  • 128
  • 3
    Can we increase `after 1000 hint_gc` so the warning happens after `10000` loose objects? – sashoalm Feb 17 '17 at 09:19
  • @sashoalm I agree. Its there for a reason. – HankCa Nov 28 '17 at 21:39
  • Wondering what exactly the good reasons are, that dialog is such a pain, without good reasons clearly explained, I am certainly very tempted to just whack in the above command. – Josh Mc May 15 '18 at 06:28
  • 3
    @sashoalm: Maybe this is what you mean, but the "1000" of `after 1000` refers to the number of milliseconds to wait until the dialog is shown. By increasing it to "10000", the dialog will still appear, but it will take 10 seconds for it to do so instead. – fuglede Aug 06 '18 at 06:25
  • 1
    However, as mentioned in @NickDandoulakis's answer, `database.tcl` contains the definition of the limit and can be increased to make the dialog less frequent. – fuglede Aug 06 '18 at 06:36
  • 1
    Better deal with the problem than disable the warning. Close `Git GUI`, open `Git Bash` and run the command `git gc --aggressive`. Now re-open `Git GUI`. – AlainD Jan 09 '21 at 20:11
  • 1
    @AlainD git already does garbage collection on its own every now and then, as part of other git commands, when it deems it necessary. So I'd argue git gui's warning and the user manually running `git gc` are (typically) unnecessary, and unnecessarily opinionated of git gui. – tjalling May 17 '21 at 12:51
55

Update: git prune would "solve" the issue, in that it will remove those loose objects
(git gc calls git prune, but only for loose objects older than two weeks, by default).
However, as the OP Michael Donohue mentions in the comments:

I do like the safety aspect of keeping the loose objects around for two weeks, should I want to go back and look at some old revisions, so I don't really like this solution.
I am not having any trouble with the size or performance of git, it is just 'git gui' that insists on asking me to compress the database, even when compressing the database would have no effect.

Original answer:

The problem of "git gc" not removing all loose objects has been reported before (late 2008, ""git gc" doesn't seem to remove loose objects any more"

git gc only removes loose objects older than two weeks, if you really want to remove them now, run git prune.
But make sure no other git process can be active when you run it, or it could possibly step on something.

"git gc" will unpack objects that have become unreachable and were currently in packs.
As a result, the amount of disk space used by a git repository can actually go up dramatically after a "git gc" operation, which could be surprising for someone who is running close to full on their filesystem, deletes a number of branches from a tracking repository, and then does a "git gc" may get a very unpleasant surprise.

[Example:] Old branches are reserved via a tag such as next-20081204.
If you update the your local copy of the linux-next repository every day, you will accumulate a large number of these old branch tags.
If you then delete a whole series of them, and run git-gc, the operation will take quite a while, and the number of blocks and inodes used will grow significantly.

They will disappear after a "git prune", but when I do this housekeeping operation, I've often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository option to "git gc".

So in your case, would a "git prune" be helpful?

(possibly with using "now" in the gc.pruneexpire config variable, needed for the above behavior to happen).

You also have (from the same thread):

repack -a -d -l

Notice the lowercase 'a'.

git-gc calls repack with uppercase 'A' which is what causes the unreachable objects to be unpacked. Little 'a', is for people who know what they are doing, and want git to just drop unreachable objects.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    'git prune' would probably solve my immediate problem - I'll try it later today. However, I do like the safety aspect of keeping the loose objects around for two weeks, should I want to go back and look at some old revisions, so I don't really like this solution. I am not having any trouble with the size or performance of git, it is just 'git gui' that insists on asking me to compress the database, even when compressing the database would have no effect. – Michael Donohue Jul 10 '09 at 11:48
  • very helpful comment. That annoying "loose object" message was getting really annoying. Where does that count come from anyway? The output of git-fsck, perhaps? – David Dombrowsky Oct 07 '09 at 14:57
  • thanks - i also had loose objects that git gc wasn't removing - git prune was the answer. – shedd Mar 19 '12 at 21:57
  • I did a git prune outside of any repository and it cleared up some of the objects. Then I went into the problem repository and did a git prune and all problems were gone. – Nicholas Orlowski Jan 30 '13 at 15:50
  • "git prune" solves the problem OP (and I) had: " I've done this before, and it reduces the loose objects to about 250, but that doesn't suppress the popup." – Eike Oct 01 '19 at 07:44
  • @Eike does a `git gc` suggested below get rid of the popup (as stated below)? – VonC Oct 01 '19 at 08:41
  • @VonC I only tried "git prune", and this did get rid of the popup for me. – Eike Oct 21 '19 at 08:01
  • It seems like a good idea to unpack loose objects because those objects will go away within 2 weeks. So if you can wait for that period of time that makes sense. – usr Feb 16 '20 at 14:38
37

When "Loose Object" popup I know it's time to run git's garbage collector:

git gc

After that the popup goes away.

Update: (due to T.E.D.'s suggestion)

I extracted the below routine from git/share/git-gui/lib/database.tcl
You can modify it to meet your needs.

proc hint_gc {} {
    set object_limit 8
    if {[is_Windows]} {
        set object_limit 1
    }

    set objects_current [llength [glob \
        -directory [gitdir objects 42] \
        -nocomplain \
        -tails \
        -- \
        *]]

    if {$objects_current >= $object_limit} {
        set objects_current [expr {$objects_current * 256}]
        set object_limit    [expr {$object_limit    * 256}]
        if {[ask_popup \
            [mc "This repository currently has approximately %i loose objects.

To maintain optimal performance it is strongly recommended that you compress the database when more than %i loose objects exist.

Compress the database now?" $objects_current $object_limit]] eq yes} {
            do_gc
        }
    }
}
Nick Dandoulakis
  • 42,588
  • 16
  • 104
  • 136
  • 1
    Doesn't clicking OK in the dialog do just that? If gc didn't get rid of all the loose objects he'd still get the dialog. – T.E.D. Jul 09 '09 at 22:01
  • I've clicked 'OK' and I've run 'git gc' from the command line - they both get me down to 250, but doing it again makes no further progress. – Michael Donohue Jul 09 '09 at 22:22
  • 3
    I know it's weird but cleaning the base from gui sometimes leaves loose objects. I close the gui, run git-gc, and then all garbage are gone. – Nick Dandoulakis Jul 09 '09 at 22:24
  • 3
    Changing the tcl fixes it - I just upped the windows limit to 10 * 250. Thanks! – Michael Donohue Jul 10 '09 at 13:23
  • 1
    for me running `git gc` from the command line solved the problem... just clicking `ok` in git gui somehow did not do the trick... – raphael Feb 18 '20 at 17:03
3

Hmmmm....I don't see a command-line argument for that in the docs.

I suppose you could always pull down its source, take out the code for the dialog, and rebuild.

T.E.D.
  • 44,016
  • 10
  • 73
  • 134
0

To add to the answers and explanations:

If you want to continue monitoring the loose objects, but not want the popup to disappear completely (it pops all the time for larger projects), you can modify database.tcl which is probably in this folder:

C:\Program Files\Git\mingw64\share\git-gui\lib\

In the function proc hint_gc {}

proc hint_gc {} {

set ndirs 1
set limit 8
if {[is_Windows]} {
    set ndirs 8
    set limit 1
}

You can change the

set ndirs 8

to

set ndirs 32

for example.

Valmond
  • 2,897
  • 8
  • 29
  • 49