在提交到存储库之前解压缩压缩数据文件

Question

以某种方式在存储库中存储正常压缩文件的“未压缩”版本是否有意义？

如果是这样，有没有标准的方法来实现这个？ （也许是一个标准的预提交挂钩，将每个这样的文件解压缩到一个特别命名的文件夹中； 以及将此类特殊命名的文件夹压缩为 LibreOffice 知道如何读写的压缩文件的结帐后挂钩？类似于“我应该在归档之前解压缩 zip 吗？” 所描述的过程？） （也许破解版本控制软件的代码来自动解压旧版本和新版本并存储解压文件之间的差异，如果失败或没有提供显着改进，则退回到原来的存储系统原始文件之间的直接差异，还是直接存储文件？）

我有一组经常编辑的 OpenOffice / LibreOffice 文件。 我将它们存储在版本控制存储库中—— 正如“图像应该存储在 git 存储库中吗？” 所推荐的那样。 虽然我碰巧使用 TortoiseHg 或 SourceTree 来访问我的存储库，而不是 git。

我碰巧知道 Open Office 文件实际上是 zip 压缩容器，里面有一些 XML 文件。 （我听说许多其他流行的应用程序“二进制文件格式”也是某种形式的 zip 压缩文件）。

我的理解是，即使是对此类“二进制”文件的最小更改也会导致整个新文件存储在存储库中。 与“文本”文件中的小改动相反，这导致仅存储和传输更改。

从理论上讲，这将具有以下优点：

• 只有几个单词的变化，我可以在更改日志的“diff”视图中看到确切的单词变化。 （而不是非信息性的“二进制文件已更改”消息）。
• 当几个不同的人独立编辑文件的第 14 版时，将他们的所有改进合并到文件的第 16 版中而不会出现回归会容易得多。
• 更快地同步到远程存储库——只需要传输简短的“更改”，而不是整个（压缩的）文件。
• 就磁盘空间而言，存储库可能更小——经过几百次更改后，我希望一个相对较小的存储库只包含几百个小更改，而不是一个包含这些文件的几百个完整副本的相对较大的存储库。 （我最后列出了这个优势，因为在当今廉价的磁盘空间中它几乎无关紧要）。

Answer 1

以某种方式在存储库中存储正常压缩文件的“未压缩”版本是否有意义？

这很有意义，尤其是当你需要分支和差异时。

这个旧线程（死链接）（存档这里）总结了情况。

1. 对于大小由嵌入图像和其他大对象主导的 Openoffice 文档，git delta 机制已经表现得相当好，因为 OO 文件是 Zip 存档，其中每个文件都是单独压缩的。
   如果您不更改图像，则该图像将以相同的方式存储，并且 三角洲可以做到。 2. 对于大小以普通内容为主的 OO 文档，git delta 机制无法工作，因为 zip 压缩引入了“混合”，文档中的小变化会转换为 zip 文件中的非常大的变化。

可以写一个

clean

过滤器在提交前解压缩。
然而，在结帐时使用互补的

smudge

过滤器有一个技巧。如果你没有正确涂抹，git 总是显示文件已更改 wrt 索引。
正确涂抹意味着使用与 OO 使用的压缩率和压缩方法完全相同，这可能有点棘手。我已经尝试在

clean

和

smudge

阶段使用 zip 二进制文件，但效果不佳。弄脏的文件总是和原来的不一样
人们可能应该在较低级别工作，以便更好地控制正在发生的事情（libzip），并在未压缩的文件前加上要在弄脏时恢复的压缩参数。

然而，更大的问题是，在处理大型 OO 文件时，清理/涂抹的东西可能真的很慢。