这可能永远不会发生在现实世界中,并且可能永远不会发生,但让我们考虑一下:假设您有一个git存储库,进行提交,并且变得非常不幸:其中一个blob最终拥有相同的SHA-1另一个已存在于您的存储库中.问题是,Git将如何处理这个？简直失败了？找到一种方法来链接两个blob并根据上下文检查哪一个需要？
更多的是脑筋急转弯而非实际问题,但我发现这个问题很有趣.
据我所知,当Git为文件分配SHA1哈希时,该SHA1对于文件的内容是唯一的.
因此,如果文件从一个存储库移动到另一个存储库,则该文件的SHA1保持不变,因为其内容未更改.
Git如何计算SHA1摘要？它是在完整的未压缩文件内容上执行的吗？
我想模仿在Git之外分配SHA1.
我正在尝试计算文件的SHA-1值.
我编造了这个脚本:
def hashfile(filepath):
sha1 = hashlib.sha1()
f = open(filepath, 'rb')
try:
sha1.update(f.read())
finally:
f.close()
return sha1.hexdigest()
对于特定文件,我得到这个哈希值:
8c3e109ff260f7b11087974ef7bcdbdc69a0a3b9
但是当我用git hash_object计算值时,我得到这个值: d339346ca154f6ed9e92205c3c5c38112e761eb7
他们怎么不一样？我做错了什么,或者我可以忽略它的区别？
上下文:我从code.google 下载了一个文件(Audirvana 0.7.1.zip)到我的Macbook Pro(Mac OS X 10.6.6).
我想验证校验和,该特定文件的校验和发布为862456662a11e2f386ff0b24fdabcb4f6c1c446a(SHA-1). git hash-object给了我一个不同的哈希,但openssl sha1返回了预期的862456662a11e2f386ff0b24fdabcb4f6c1c446a.
以下实验似乎排除了任何可能的下载损坏或换行差异,并表明实际上有两种不同的算法在起作用:
$ echo A > foo.txt
$ cat foo.txt
A
$ git hash-object foo.txt
f70f10e4db19068f79bc43844b49f3eece45c4e8
$ openssl sha1 foo.txt
SHA1(foo.txt)= 7d157d7c000ae27db146575c08ce30df893d3a64
这是怎么回事？
git树对象的内容格式是什么？
blob对象的内容是blob [size of string] NUL [string],但对于树对象是什么？
使用OS X终端,
如何以纯文本格式查看这些文件的内容？
上下文:我希望能够通过我的git提交消息和提交进行搜索而无需经历令人费解的复杂git grep命令,因此我决定看看如何存储git commit消息.
我看了一下.git文件夹,它看起来像是存储的提交
.git/objects
.git对象文件夹包含一堆名称为a6和9b的文件夹.这些文件夹中的每个文件夹都包含一个名称类似于提交的文件2f29598814b07fea915514cfc4d05129967bf7.当我在文本编辑器中打开其中一个文件时,我会感到胡言乱语.
在这个git commit日志中,文件夹9b包含一个commit sha
aed8a9f773efb2f498f19c31f8603b6cb2a4bc
为什么,并且是否存在多个提交sha将存储在文件9b中的情况？
有没有办法将这个乱码转换成纯文本,以便我可以在文本编辑器中混淆提交？
我熟悉Git 如何为文件（blob）创建 SHA1 哈希值，但不熟悉如何为标签对象创建它们。如果我创建一个带注释的标签，我认为它们是，但是配方是什么？我如何在 Git 之外复制它（例如，在 Perl 或 Python 中）？
我有一个文件，其内容是“来自测试”- 9 个字节。文档说创建的文件的 SHA 是使用 SHA1 计算的：
计算文件的 SHA-1 哈希值并将其存储在 blob 对象中。
（来自https://developer.github.com/v3/git/blobs/）
然而，当我计算“from test”的十六进制编码的 SHA1 输出时，我得到5669556d9a5c27fdd649dcaaa0873757c2aa402f.
Github API 表示 SHA 是62b551731eada762035d4665978027cd44291290- 这是返回的 ETag 以及用于检索文件的 API 响应中“sha”的值。此外，当我使用“from test”作为值和566955...sha 调用 CreateFile 端点时，我被告知 SHA 不正确。
我还尝试附加换行符，计算内容的base64编码值的SHA，计算base64+尾随换行符的SHA，但它们都没有给我62b551731eada762035d4665978027cd44291290. Github 是如何计算这个值的？
我已经仔细检查了远程文件的内容是否相同 - “来自测试” - 不知何故 SHA 仍然不同。
我看过这篇文章，它提到 Git 对我正在使用的版本使用 SHA-1 哈希。然而，当我将 的输出git hash-object与熟悉的进行比较时sha1sum，我得到了不同的结果。例如：
$ git --version
git version 2.17.1
$ git hash-object data/letter.txt
2e65efe2a145dda7ee51d1741299f848e5bf752e
$ sha1sum data/letter.txt
86f7e437faa5a7fce15d1ddcb9eaeaea377667b8 data/letter.txt
我正在关注这个帖子。该文件letter.txt包含一个字母“a”。
为什么这些命令会产生不同的结果？
当在github上使用来自未知第三方的代码时,我总是确保检查代码中没有可能危及系统安全性的明显后门存在.
我正在审查的存储库的特定状态可能绑定到git标记和提交哈希.众所周知,git标签的内容很容易改变.因此,再次下载源代码并基于版本标记信任它绝对不安全.
我的问题是:在下载新的源代码下载时,我是否可以相信,如果我根据它的完整提交哈希签出特定提交,那么这与我之前审查过的代码完全相同？
这个问题的焦点不在于完全发生sha1碰撞的可能性(因为碰撞比计算特定的sha1散列更容易计算 - 有希望 - 目前几乎不可能？),但是是否每个每个文件都是此sha1 sum的一部分,因此更改将始终触发不同的哈希.