How to skip "Loose Object" popup when running 'git gui'
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
)
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 asnext-20081204
.
If you update the your local copy of thelinux-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 rungit-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.
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 } }}