你应该多久使用一次git-gc？

你应该多久使用一次git-gc？

该手册只是说:

建议用户定期在每个存储库中运行此任务,以保持良好的磁盘空间利用率和良好的运行性能.

是否有一些命令来获取一些对象计数,以确定是否需要gc的时间？

1> Adam Davis..：

---

这主要取决于存储库的使用量.一个用户每天检查一次,每周一次分支/合并/等操作,您可能不需要每年运行一次以上.

有几十个开发人员正在处理几十个项目,每个项目每天检查2-3次,您可能希望每晚运行它.

但是,运行它的频率不会超过需要.

我现在要做的就是现在运行它,然后从现在起一周后测量磁盘利用率,再次运行它,并再次测量磁盘利用率.如果它的尺寸下降了5%,那么每周运行一次.如果它下降更多,则更频繁地运行它.如果它减少了,那么不那么频繁地运行它.

---

"运行它的频率不会超过需要"......我不完全同意.正如亚里士多德指出的那样,悬挂的提交可以成为一个很好的备份机制.

---

手册说"执行可能会创建许多松散对象的操作后,某些git命令会运行git gc --auto".有谁知道哪些命令实际运行它？

2> Aristotle Pa..：

---

请注意,垃圾收集存储库的缺点是收集垃圾.众所周知,作为计算机用户,我们现在认为垃圾的文件可能会在未来三天变得非常有价值.git保留了大部分碎片的事实已经多次保存我的培根 - 通过浏览所有悬挂的提交,我已经恢复了很多我意外罐装的工作.

因此,不要在你的私人克隆中做太多整洁的怪物.几乎没有必要.

OTOH,数据可恢复性的价值对于主要用作遥控器的repos是有问题的,例如.所有开发者推动和/或拉动的地方.在那里,开始GC运行和频繁重新包装可能是明智的.

---

FWIW并非所有松散的对象都是垃圾收集的,默认情况下只有2周以上(参见`git gc --help`,特别是`--prune`选项).还提到了`gc.reflogExpire`,这让我相信你在过去90天内访问过的任何提交都不会被收集.(我的git版本:v1.7.6)

---

一个男人的垃圾是另一个男人的财宝;)

---

这些都不会影响我的观点,但是,这是正确的.

3> mrowe..：

---

最新版本的git会在需要时自动运行gc,因此您不必执行任何操作.请参阅man git-gc(1)的Options部分:"执行可能会创建许多松散对象的操作后,某些git命令会运行git gc --auto."

---

我刚刚在一个有数年历史的存储库中运行它,而我的.git从16M上升到2.9M,大小减少了82%.因此,手动运行命令似乎仍然有用.

4> cregox..：

---

如果您正在使用Git-Gui,它会告诉您何时应该担心:

This repository currently has approximately 1500 loose objects.

以下命令将带来一个类似的数字:

$ git count-objects

除了从它的来源,git-gui将自己做数学,实际上在.git/objects文件夹中计算一些东西并且可能带来近似值(我不知道tcl要正确读取它!).

在任何情况下,它似乎都会根据大约 300个松散物体的任意数字给出警告.

5> Pat Notz..：

---

把它放在一个每天晚上(下午？)睡觉的cron工作中.

6> Rory..：

---

我做了大量结账后使用git gc,并且有很多新对象.它可以节省空间.例如,如果您使用git-svn签出一个大型SVN项目,并执行git gc,通常可以节省大量空间

7> VonC..：

---

使用新的(Git 2.0 Q2 2014)设置,您可以在不中断的情况下完成gc.autodetach.

请参阅commit 4c4ac4d并提交9f673f9(NguyễnTháiNgọcDuy,又名pclouds):

gc --auto需要时间并且可以暂时阻止用户(但不要那么烦人).
使其在支持它的系统的后台运行.
在后台运行时唯一丢失的是打印输出.但gc output并不是很有趣.
您可以通过更改将其保持在前景中gc.autodetach.

---

从2.0发布以来,虽然有一个bug:git 2.7(2015年第4季度)将确保不会丢失错误消息.
见提交329e6e8通过(2015年9月19日)阮泰玉维战(pclouds).
^{(由Junio C gitsterHamano合并- -在提交076c827,2015年10月15日)}

gc:从daemonized保存日志gc --auto并在下次打印它

虽然提交9f673f9(gc:--auto在后台运行的配置选项- 2014-02-08)有助于减少一些关于gc --auto"占用终端" 的抱怨,但它会产生另一组问题.

作为守护程序的结果,此集合中的最新内容stderr已关闭,并且所有警告都将丢失.最后的警告cmd_gc()特别重要,因为它告诉用户如何避免gc --auto重复运行.
因为stderr关闭了,用户不知道,他们自然会抱怨gc --auto"浪费CPU".

Daemonized gc现在保存stderr到$GIT_DIR/gc.log.
在用户删除之前,以下内容gc --auto将不会运行并gc.log打印出来gc.log.

8> Teoman shipa..：

---

这句话取自; 使用Git进行版本控制

Git自动运行垃圾收集:

•如果存储库中有太多松散的对象

•发生推送到远程存储库时

•在一些可能引入许多松散对象的命令之后

•当某些命令(例如git reflog)到期时明确请求它

最后,当您使用git gc命令显式请求时,会发生垃圾收集.但什么时候应该呢？这个问题没有可靠的答案,但有一些好的建议和最佳实践.

你应该考虑在几种情况下手动运行git gc:

•如果您刚刚完成了git过滤器分支.回想一下,filter-branch重写了许多提交,引入了新的提交,并将旧的提交保留在ref上,当你对结果感到满意时应该删除它.应该通过垃圾收集删除所有那些死对象(因为你刚刚删除指向它们的一个引用而不再引用它们).

•在一些可能引入许多松散对象的命令之后.例如,这可能是一个很大的变革努力.

另一方面,你什么时候应该警惕垃圾收集？

•如果存在您可能想要恢复的孤立引用

•在git rerere的上下文中,您不需要永久保存分辨率

•仅在标记和分支足以导致Git永久保留提交的上下文中

•在FETCH_HEAD检索(通过git fetch进行URL直接检索)的上下文中,因为它们立即受到垃圾回收

•仅在标记和分支足以导致Git永久保留提交的上下文中

•在FETCH_HEAD检索(通过git fetch进行URL直接检索)的上下文中,因为它们立即受到垃圾回收

---

我的树中有无法访问的提交(由于`git commit --amend`).这可以通过`git log --reflog`来验证.我将一个分支推送到远程存储库并再次检查我的树; 无法访问的提交仍然存在.显然,当这个推动发生时,`git gc`没有运行.......？