当我运行“git gui”时，我得到一个弹出窗口，上面写着
该存储库目前大约有 1500 个松散对象。然后它建议压缩数据库。我以前做过这个，它将松散的对象减少到大约 250 个，但这并没有抑制弹出窗口。再次压缩不会改变松散对象的数量。
当我们从 Perforce 过渡时，我们当前的工作流程需要大量使用“rebase”，而 Perforce 仍然是规范的 SCM。一旦 Git 成为规范的 SCM，我们将进行定期合并，并且应该大大缓解松散对象问题。
与此同时，我真的很想让这个“有用的”弹出窗口消失。
【问题讨论】：
标签： git garbage-collection rebase git-gui git-gc
添加答案和解释：
如果您想继续监控松散对象，但不想让弹出窗口完全消失（对于较大的项目，它一直弹出），您可以修改可能在此文件夹中的 database.tcl：
C:\Program Files\Git\mingw64\share\git-gui\lib\
在函数 proc hint_gc {}
proc hint_gc {} {
set ndirs 1
set limit 8
if {[is_Windows]} {
set ndirs 8
set limit 1
}
你可以改变
set ndirs 8
到
set ndirs 32
例如。
【讨论】：
由于没有人回答，我查看了代码以了解如何删除显示该对话框的代码。我找到了执行此操作的hint_gc 过程以及调用它的位置。同时我注意到在 2011 年末添加了a configuration option for disabling the dialog。此更改（git-gui 0.16.0 的一部分）已合并到 2011-12-14 上的 Git 主线。
因此，如果您使用 Git v1.7.9 或更高版本，您可以使用以下命令禁用警告对话框：
git config --global gui.gcwarning false
如果您使用的是旧版本，则可以编辑 /lib/git-core/git-gui 并删除 after 1000 hint_gc 行，或编辑 /usr/share/git-gui/lib/database.tcl 并删除 hint_gc 过程的主体。 （这些文件路径位于 Cygwin 上 - 在其他环境中，文件可能位于不同的位置。对于 Windows，它是 c:\Program Files\Git\mingw64\libexec\git-core\git-gui.tcl）
【讨论】：
after 1000 hint_gc 以便在10000 松散对象之后发生警告吗？
after 1000 的“1000”是指等待显示对话框的毫秒数。通过将其增加到“10000”，对话框仍然会出现，但它需要 10 秒才能完成。
database.tcl 包含限制的定义，可以增加以降低对话频率。
git gc 的用户（通常）是不必要的，并且不必要地固执己见。
更新：git prune 将“解决”问题，因为它将移除那些松散的对象
（git gc 调用 git prune，但默认情况下仅适用于超过两周的松散对象）。
然而，正如 OP Michael Donohue 在 cmets 中提到的那样：
我确实喜欢将松散的物体放置两周的安全方面，如果我想回去看看一些旧的修订版，所以我不太喜欢这个解决方案。
我对 git 的大小或性能没有任何问题，只是 'git gui' 坚持要求我压缩数据库，即使压缩数据库没有效果。
原答案：
“git gc”没有删除所有松散物体的问题之前已经报告过（2008年末，“"git gc" doesn't seem to remove loose objects any more”
git gc只删除超过两周的松散对象，如果您现在真的想删除它们，请运行 git prune。
但是请确保在您运行它时没有其他 git 进程处于活动状态，否则它可能会单步执行 在某事上。"
git gc" 将解包已变得无法访问且当前位于包中的对象。
因此，在“git gc”操作之后，git 存储库使用的磁盘空间量实际上会显着增加，这对于在文件系统上运行接近满的人来说可能会令人惊讶，从跟踪存储库中删除多个分支，然后执行“git gc”可能会得到非常不愉快的惊喜。
[Example:]旧分支通过next-20081204等标签保留。
如果你每天更新你本地的linux-next仓库副本，你会积累大量这些旧的分支标签。
如果你然后删除一整串，然后运行git-gc，操作将需要相当长的时间，并且使用的块和inode的数量会显着增加。他们会在“
git prune”之后消失，但是当我做这个家务操作时，我经常希望“git gc”有一个--yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository选项。
那么在你的情况下，“git prune”会有帮助吗？
（可能在gc.pruneexpire 配置变量中使用“now”，这是发生上述行为所必需的）。
你也有（来自同一个线程）：
repack -a -d -l
注意小写的“a”。
git-gc使用大写的“A”调用 repack，这会导致无法访问的对象被解包。小 'a'，适用于那些知道自己在做什么，并希望 git 只删除无法访问的对象的人。
【讨论】：
当“Loose Object”弹出窗口时，我知道是时候运行 git 的垃圾收集器了：
git gc
之后弹出窗口消失。
更新：（根据 T.E.D. 的建议）
我从git/share/git-gui/lib/database.tcl 中提取了以下例程
您可以对其进行修改以满足您的需求。
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
}
}
}
【讨论】：
git gc 解决了这个问题......只是在 git gui 中单击 ok 不知何故没有解决问题......
嗯……我在docs 中没有看到命令行参数。
我想你总是可以拉下它的源代码，取出对话框的代码，然后重新构建。
【讨论】：