问题标签 [git-gc]

我可以在 Git 中对大型存储库使用单线程压缩，而对小型存储库使用通常的并行压缩吗？像“pack.threads=1”如果不容易放入记忆中，“pack.threads=4”否则。

正如我心中的某个地方，多线程“git gc”需要大量内存并且比单线程更长时间地颠簸（或只是失败）。

我希望它在小型回购中快速运行，并且在大型回购中不会失败。

我正在git gc --aggressive一个非常大的仓库（apx 100 gb）上运行。它从两晚前开始运行，几个小时后，它一直卡在：“压缩对象：99% (76496/76777)”

如果我Ctrl-C过程，有什么后果？我的回购将无法使用吗？我的直觉说不，但我想要一些意见。谢谢！

最终更新和修复：这里的解决方案结果是两件事的结合：使用 Windows Git 而不是Graham Borland 建议的 Cygwin Git，以及 Git 配置设置pack.threads = 1和gc.aggressiveWindow = 150.

我有一个大型的本地 Git 存储库，git svn clone一个 SVN 存储库，大约有 40,000 次提交。我正在尝试运行git gc此存储库，但无处可去：

我在具有 4GB RAM 的 64 位双核 Win7 机器上在 Cygwin 中运行 Git 1.7.5.1。该.git目录目前略大于 6.1GB。

我试过运行git gc --aggressive，看看更完整的系统是否能够修复它，但没有运气：我收到与上述类似的消息，尝试了相同的大小malloc，但对象计数要高得多（计数为 508,485，压缩为 493,506 ）。

我也尝试过——正如谷歌所建议的——对我的文件[pack]部分进行各种旋转；.gitconfig最完整的来自另一个 StackOverflow 问题。我.gitconfig现在有以下相关行，但设置这些似乎没有任何区别：

关于如何git访问gc我的存储库的任何建议？

编辑：Mark Longair 建议进行更多.gitconfig文件更改。我做的，下面有新的行。但是这些变化没有任何区别。

编辑 2：Michael Krelin 建议增加交换/页面文件大小（此处为WinXP 说明，与 Win7 类似）。我试过了，但没有任何区别，实际上我只是增加了可用的最大大小，而且看起来 Windows 从未尝试增加它正在使用的页面文件的大小。

我现在正在研究这是否是由于 Cygwin 内部的内存限制或强加于 Cygwin 造成的。要检查“强加于”，我正在尝试以管理员权限运行 Cygwin。为了检查“内部”（看起来更有可能），我正在玩Cygwin 的最大内存设置。

编辑 3：虽然我可能更喜欢使用 Cygwin，但事实证明 Windows Git 客户端可以很好地处理内存问题。似乎当我的存储库需要整理时，我会经常退回到那个位置。

当我运行git gc或git repack遍历我的 Git 存储库时，它会在完成后输出一个“Total”行。这些数字是什么意思？

来自一个相当小的存储库的几个示例：

还有一个来自更大的存储库：

我可以猜到第一个“Total”数字是多少：存储库中 Git 对象（即提交、树和文件）的数量。所有其他人实际上是什么意思？

我已经查看了手册页，git-gc(1)并git-repack(1)仔细阅读了他们的“另请参阅”，而我在谷歌上搜索的尝试只产生了不相关的结果。

我在 Dreamhost 托管的具有 2GB 内存的虚拟服务器上使用 Git。我git gc每天早上 4 点运行，并且在过去一周中一直运行，dreamhost 进程重新启动发送一封电子邮件，说明由于我消耗了超过 2GB 的内存，他们已经重新启动了我的服务器以停止消耗内存的进程。

存储库大小为 10GB。在发布此之前我已经进行了广泛的查看，但是是否有 Git 创建的日志文件可以让我看到 Git 正在“触摸”哪个文件导致服务器强制重启？

问题

这听起来像是一个 GitExtensions 错误，我找不到特定的信息。我相信当您拥有一个包含 1 个以上分支的裸存储库时，就会出现问题。如果你再推，你会得到一个警告，如果你选择忽略你会发现混乱的分支。或者取决于你如何推动它，甚至没有出现警告，而且到处都是厄运！

假设我们有 2 个名为masterand的本地分支another。并且默认origin设置为推送。在定期推送之后，我们还会找到origin/masterand origin/another，仅此而已。

但是在注定的推动之后，我们会发现重复origin/master和加origin/another号origin/refs/heads/master，这也是重复的。对于每一个额外的分支。这不像我们要推送所有分支或其他东西，也不是我们使用Multiple Branches 功能。

事实上，发生这种情况后，我们甚至不能简单地push没有错误！（是的，当然使用 Windows）

当列出带有git branch -r.

要解决这个问题

我们需要做这样的事情：

1. 手动删除. _ 有时它只使用，其他时候我们需要更健壮并直接进入文件夹。这是困难的一步，主要问题发生在那些不起作用时......refs/heads origin git push origin :<branchName>
2. git fetch -p，用于将原点更改带到本地。
3. 最终通过所有客户端并使用git remote update. 如果需要，可以一个一个或通过任何方式删除相同的分支，例如再次健壮地直接进入文件夹。这个步骤中还有另一个问题，有时我还无法诊断。

频率

对我们来说，这是一个既定事实。尽管我没有做很多实验来看看究竟是什么原因造成的，但它确实发生在使用这个 repo 的 5 台机器中的任何一台上，除了bare.

每次发生这种情况时，我都必须运行并找出如何解决它。这次我决定把它记录下来，因为我在网上找不到足够具体的东西。

为什么

这里的问题是：为什么会发生这种情况，以及如何预防？它甚至只是 GitExtensions 错误吗？在我们这边，这肯定会发生，只有在 GitExtensions 中这个特定的场景。

似乎 git 拒绝在我的远程存储库上自动执行 gc 命令。在大约一个月内，由于 .pack 文件，存储库扩大到大约 6GB。我认为这是变量 gc.auto 的问题-如何在远程存储库上设置此变量，或者如何在该存储库上手动运行 git-gc 命令？

在过去，一个人不得不git gc不时调用。我现在读到，最新的 Git 版本应该自动执行清理。它是否正确？

我有一个反复出现的问题，我的 git repo（我认为？）将决定它需要进行垃圾收集。这个过程需要半个多小时，然后会在每次拉/推操作时触发。

手动运行 Git GC 需要半小时，但似乎无法解决问题。我发现的唯一解决方案是删除我的 repo 并重新克隆，由于许多原因，这是次优的。

我的 git GC 操作可能很慢，因为我设置了 git 一些内存限制以阻止它在 git GC 操作中崩溃，就像它曾经在达到 4gb Windows 内存限制然后崩溃时那样。

任何帮助，将不胜感激。这是一个大型 repo，repo 确实包含大量二进制数据，以及大量非常大（> 500k）的文本文件。

那么，1. 我如何限制 Git 决定进行垃圾收集的数量。2.如何加快GC运行速度？3. 我能做些什么来解决或最小化所涉及的更大问题（也就是为什么它必须首先进行垃圾收集）？

由于几年前签入了许多大 blob，我的存储库变得非常大。它们已在后续修订中被删除，不再需要，所以我现在应该能够清除对它们的任何引用。

我看过一些关于使用的参考，git filter-branch但使用这个命令似乎很危险而且很笨拙，所以我尝试了这个：

这难道不应该意味着在历史的任何时候创建并随后删除的任何内容都将被永久删除吗？

出于某种原因，它似乎不起作用 - 大小或多或少相同。

有什么建议么？