无法复制commit的Pro Git构造

Question

我正在构建我自己的Git实现，并且我的输出(以及git本身的输出)已经脱离了point的输出。

具体来说，现在我正在通过https://git-scm.com/book/en/v2/Git-Internals-Git-Objects的构造来构建一个commit。但是，即使在修复了提交数据的全部内容之后，我似乎也无法得到相同的提交散列。我编写了一个小程序来编写和读取提交，该程序能够往返我指定的提交数据，但是它得到了“错误”的提交哈希。该“错误”提交哈希与我的本地git一致，但与Pro的打印输出不一致。

为了方便起见，在zsh中复制它(当我使用自己的Git实现时，这里得到的提交散列与git完全相同)：

➜  git --version
git version 2.26.1 
➜  rm -rf .git
➜  export GIT_AUTHOR_DATE="2009-05-22T18:09:34+00:00-0700"
export GIT_AUTHOR_EMAIL="schacon@gmail.com"
export GIT_AUTHOR_NAME="Scott Chacon" \
export GIT_COMMITTER_DATE="2009-05-22T18:09:34+00:00-0700" \
export GIT_COMMITTER_EMAIL="schacon@gmail.com" \
export GIT_COMMITTER_NAME="Scott Chacon" \

git init

# First commit.
echo 'version 1' > test.txt
git add test.txt
echo 'First commit' | git commit -F -
Initialized empty Git repository in /Users/Patrick/Documents/Experiments/foo2/.git/
[master (root-commit) 70d4408] First commit
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

➜  git cat-file -p 70d440
tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
author Scott Chacon <schacon@gmail.com> 1243040974 -0700
committer Scott Chacon <schacon@gmail.com> 1243040974 -0700

First commit
➜

相比之下，斯科特在书中的输出是：

$ echo 'First commit' | git commit-tree d8329f
fdf4fc3344e67ab068f836878b6c4951e3b15f3d

$ git cat-file -p fdf4fc3
tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
author Scott Chacon <schacon@gmail.com> 1243040974 -0700
committer Scott Chacon <schacon@gmail.com> 1243040974 -0700

First commit

请注意，我从书的输出中得到了相同的数据，但是提交散列(我的是70d44，Scott的是fdf4f)。

为什么我们有不同的哈希？这是否与zlib压缩级别的变化有关？在这里，这似乎是唯一可能的变量，但是无论我使用的zlib压缩级别如何，我的结果都是一样的(因为更改这一点的能力暴露在.NET的Ionic.Zlib中)。一种可能的解释是，自本书编写以来，zlib已经发生了变化，最近的zlib在2.26.1版本中被Ionic.Zlib和git使用；但是它没有完全改变，因为我已经尝试过为树和blob对象获得正确的散列。

我对行尾非常小心:我的提交消息末尾有一个换行符，Scott也是这样，因为这两条消息都来自echo。总之，我对我的结果很有信心:我可以使用自制的Git实现进行往返提交，我的自制Git实现在这一点上与我的git (而不是Scott)一致。

Answer 1

多亏了@torek，我想回顾一下吉特书的历史。这确实是一个bug:他们更改了提交消息，而没有相应地更改散列。这个特定的提交消息过去是“第一个提交\n”(注大写)；这至少在https://github.com/progit/progit2/blob/fbb758a2369bcb02bbd8683a6a76e24e41b8e63c/book/10-git-internals/sections/objects.asc中是正确的。这个问题是由4f55250d90710652c0948853bb3ffcbd751adeee提出的，现在我来解决它。