我使用rsync将我的工作（包括Git存储库）镜像到不同的硬盘中，以此作为防止HD故障的安全措施。
默认的Git行为是尝试将已删除的.pack文件重新打包为尽可能少的文件。当然，这会导致大型.pack文件，每次Git重新打包存储库时都会对其进行修改（这样，增量中的基本数据始终是最新的提交），从而导致rsync使用的带宽超出了期望（如果您在重新包装Git后使用rsync，几乎将传输整个存储库的大小）。
寻找有效的解决方法，我发现this blog post给出了一些可能的建议：
除非我错过任何事情，否则这里有3½条建议：
完全关闭打包文件和gc，这将导致小文件 为将来的每一次变化而积累，最终将使事情成真 变慢。 gc.auto 0，gc.autopacklimit 0。
将最大包装大小设置为较小的数字，以便没有包装文件 变得太大，并且随后的差异层捆绑在一起 较小的打包文件。 pack.packSizeLimit。
对＃2的不同意见：这并没有按照您的想法做，而是 只需将单个大包文件切成N个不同的文件 它们中的相同位，因此您没有保存任何内容。
如果您已经有一个巨大的打包文件，请接下来创建一个.keep文件 对此。新的打包文件将出现，但与它们不同 节省了一个，因此更小。
研究git-config docs时，发现上面的博客文章中没有提到的设置，就我的目的而言，这可能更有趣：
gc.bigPackThreshold
如果非零，则所有大于此限制的包装均为 在运行
git gc时保留。这与--keep-base-pack非常相似 除了保留所有符合阈值的包装，而不仅仅是 基本包装。默认为零。 k，m或g的常见单位后缀为 支持。请注意，如果保留的包数大于gc.autoPackLimit， 忽略此配置变量，除基本包外的所有包 将重新包装。此后，包装数量应低于 应该再次尊重gc.autoPackLimit和gc.bigPackThreshold。
看来gc.bigPackThreshold可能比博客文章中的建议更适合我的用途（虽然不确定禁用gc.autoPackLimit是否是个好主意，还是我应该将其留给默认值为50，或将其调整为更大的值-如果禁用它不会导致不希望的副作用，那将是我的选择。
有人遇到类似情况吗？如果肯定的话，您为获得有效的rsync性能而调整了哪些Git设置？