Question

我有兴趣在git中存储固定大小的EEPROM HEX文件。文件永远不会改变大小，但它们会经常更改内容。

如果我将一个EEPROM文件添加到git并提交它，那么我会更改文件中的几个字节，git会在几十次或几百次提交中有效地存储这个更改吗？

在我对这个问题的研究中，我遇到了关于这个主题的some thorough discussions，但是他们中的大多数似乎都处理像PDF和MP3这样的文件，没有人希望保持不变或者在差异中具有可比性。我想知道EEPROM HEX文件是否会被区别对待，因为文件大小保持不变？

已编辑（再次）

一些初步观察......（感谢Krumelur“只是试一试”鼓励！）

我正在测试的文件是一个7MB的Intel HEX文件。根据git的输出，它似乎将此文件视为文本文件：

$ git commit -m "Changed a single byte."
[master bc2958b] Changed a single byte.
1 file changed, 1 insertion(+), 1 deletion(-)

diff输出也匹配：

$ git show bc2958b
commit bc2958b[...]
Author: ThoughtProcess <blah@blah.com>
Date:   Wed Jul 31 11:53:41 2013 -0500

    Changed a single byte.

diff --git a/test.hex b/test.hex
index fbdeed4..04d19b6 100644
--- a/test.hex
+++ b/test.hex
@@ -58,7 +58,7 @@
 :20470000000000000000000000000000000000000000000000000000E001EDD0D9310D00E4
 :20472000400200000080000000000000000000000000000000000000E002EDD0CF310D000B
 :20474000400200000080000000000000000000000000000000000000E0036D0063040D00D3
-:2047600040020000008000000000000000000000000000000000000000A0FF2F06801B0FF9
+:2047600040020000008000000000000000000000000000000000000000A0FF2G06801B0FF9
 :2047800000E01D007A00820F3CFB000000000000000000000000000000A0FF8F06801B1FEC
 :2047A00000E01D006A00821F3CFB000000000000000000000000000000A0FF6F06801B8F7C
 :2047C00000E01D005A00821F3CFB000000000000000000000000000000A0FF8F06801BDFFC

在7次提交后，存储库大小现在为21MB。这是奇怪的事情，我注意到每次提交时，存储库似乎都会以大致线性的大小（2MB）增长。这简直就是git的设计方式吗？或者它是不是像我期望的那样将增量差异存储为文本？

Answer 1

git实际上是在.git/objects下的某个位置存储文件的新完整副本，因此您的存储库确实会线性增长。您可以运行git gc来使git打包存储库。对于您的数据，git应该能够非常有效地打包，并且您的存储库应该变得更小。（git也会偶尔自动运行git gc。）

Answer 2

如果您真的存储了英特尔HEX格式文件，则无需担心 - 它们是文本文件。它们碰巧代表二进制数据。

来自wikipedia entry：

格式是一个文本文件，每行包含十六进制值，用于编码数据序列及其起始偏移量或绝对地址。

编辑说明：您在测试中所做的更改无效 - G不是十六进制数字，除此之外，您没有更新校验和。

Answer 3

我们可以测试git是否有效地存储了两个非常相似的二进制文件。在git版本2.9.2.windows.1上进行测试（为清楚起见，删除了额外的输出）：

$ git init
$ du -bs .git
15243   .git
$ head -c 10MB < /dev/urandom > random.bin
$ git add random.bin
$ git commit -m "Add random.bin"
$ du -bs .git
10018971        .git
$ git gc
$ du -bs .git
10020319        .git

Git以大约20 KB的开销存储10 MB的二进制文件（请注意，原始文件在目录中仍然占据另外10 MB的空间）。现在，如果我们使用文本编辑器（如果愿意，可以使用Write byte at address (hexedit/modify binary from the command line)）将文件修改几个字节：

$ vim random.bin  # modify a few bytes
$ git add random.bin
$ git commit -m "Modify random.bin a little"
$ du -bs .git
20023953        .git
$ git gc
$ du -bs .git
10021228        .git

在git gc之前，两个版本均已完全存储。之后，git非常有效地打包了两个文件。在https://codewords.recurse.com/issues/three/unpacking-git-packfiles和https://git-scm.com/docs/pack-format

中更详细地描述了Git打包文件。

$ git verify-pack -v .git/objects/pack/pack-4bc29bb6848c64b94ba6074939c851b83240dd60.pack
4ea81b3f5d4f0ef5ddbc8e9adaac73b60c0899c4 commit 201 151 12
9e2bafb8cd3a4f0fc6d0773611a92ac1b14303b0 commit 141 111 163
f2aa8f26c4dcad0f73a03c958b2eb1c0fc6cb8fd blob   10000008 10003073 274
0b650d78653ec22c19453264384ed644fc956f42 tree   38 49 10003347
bd143b12cdec07b9aa68875052c01ae6d041f28f tree   38 49 10003396
fd1a966f4b0acc4c77ab85cb81841ebb0ee290ea blob   470 309 10003445 1 f2aa8f26c4dcad0f73a03c958b2eb1c0fc6cb8fd
non delta: 5 objects
chain length = 1: 1 object
.git/objects/pack/pack-4bc29bb6848c64b94ba6074939c851b83240dd60.pack: ok

最后一个斑点是修饰的，它引用原始二进制文件的SHA-1。

进行了类似的测试in this answer。

git会存储内容发生变化的二进制文件的差异，但永远不会改变大小吗？

3 个答案: