问题标签 [git-hash]

我想保留（目前）将 Git 变更集链接到存储在 TFS 中的工作项的能力。

我已经编写了一个工具（使用来自 Git 的钩子），我可以在其中将工作项标识符注入到 Git 变更集的消息中。

我还想将 Git 提交的哈希存储在自定义 TFS 工作项字段中。通过这种方式，我可以检查 TFS 中的工作项并查看哪些 Git 变更集与该工作项相关联。

如何轻松地从 Git 的当前提交中检索哈希？

我正在编写一个脚本，需要检查特定提交是否是合并/恢复提交，我想知道是否有一个 git 技巧。

到目前为止我想出的（我绝对不想依赖这里的提交消息）是检查HASH^2我是否没有收到错误，有没有更好的方法？

存储在树对象中的 SHA1 哈希（由 返回）git ls-tree与文件内容的 SHA1 哈希（由 返回）不匹配sha1sum：

Git 如何计算文件哈希？它会在计算哈希之前压缩内容吗？

我想在 Python 脚本的输出中包含当前的 git 哈希（作为生成该输出的代码的版本号）。

如何在我的 Python 脚本中访问当前的 git 哈希？

我发现很难理解 Git 如何创建完全唯一的哈希，即使在前 4 个字符中也不允许相同。我只能使用前四个字符在 Git Bash 中调用提交。算法中是否特别决定了第一个字符是“超”唯一的并且永远不会与其他类似的散列冲突，或者算法是否以相同的方式生成散列的每个部分？

在 github 上使用来自未知第三方的代码时，我总是确保检查代码是否存在可能危及我系统安全性的明显后门。

我正在审查的存储库的特定状态可能绑定到一个 git 标记和一个提交哈希。我们知道，一个 git 标签的内容可以很容易地改变。所以再次下载源代码并根据版本标签信任它肯定是不安全的。

我的问题是：当重新下载源代码时，我是否可以相信，如果我根据完整提交哈希检查特定提交，这与我之前查看的代码 100% 相同？

这个问题的重点根本不是 sha1 冲突发生的概率（因为计算冲突比计算特定的 sha1 哈希要容易得多 - 希望 - 目前几乎不可能？），但是否每个和每个文件都是这个 sha1 总和的一部分，因此更改总是会触发不同的哈希。

g3c31c73似乎没有指向任何东西......文档说它是最近提交的缩写对象名称，但它不是 HEAD 提交哈希，并且find .git/objects -type f | grep g3c31c73什么也没找到。

我从 GIT 存储库（最新）克隆。此时，存储库中的最新提交是：a10cb09

我使用以下命令进行克隆（我在我的小包装脚本中设置变量r= 传递的第一个参数（对于 repo name aka ）：ansible

并进行了一些更改并执行了以下简单步骤：（即进行更改，添加文件/文件夹，提交和推送），我得到了一个新的提交哈希a08c263（短）。

当我要去 Github 仓库查看我的最新更改时，它不存在。git log也没有显示我的提交（相反，它向我显示了提交之前位于顶部的提交哈希）。我错过了什么？

似乎我什至看不到使用git rev-parse a08c263（小散列）的长散列。

和

PS：如果我对位于mycompanyrepo 组下的其他存储库执行相同的步骤，并且如果我遵循类似的步骤，所有这些 repos 都会在 github 中成功获得我的提交/推送更改。

更新：我的浏览器页面之一仍然打开。在我提交+推送之后，我能够看到我提交的更改（新哈希a08c263作为顶级 repo 级别的最新提交）。当我点击它时，它打开了这个附加的浏览器页面，我可以在其中看到完整的哈希以及文件夹/文件。如果我访问为我的提交打开的浏览器 URL，它仍然存在（所以 Git 确实保存了一些东西）但是单击存储库的根级别，即ansible，最新的提交不是我的提交+推送（新哈希），但它被列为a10cb09最新一个（每个快照是我新生成的哈希的父哈希）。看这里：

现在带来了主要问题：

1. 如果我还没有打开这个浏览器页面，那么我将如何获得长哈希和我的文件夹/文件（内容）？
   

2. 如果我从 github.com/mycompany/ansible (repo) 克隆，它是 ansible 存储库的 MIRROR，实际上托管在 Phabricator 中（其中实际的原始存储库克隆 URL 与我在上面的小脚本中使用的不同），那么我应该使用什么命令/选项将我的新更改推送到原始 Phabricatoransible存储库？
   

3. 如果提交+推送在我结束时完成，为什么git log和其他类似git的命令没有显示任何针对我的新哈希的信息？

假设我想编写一个小助手，允许以可以传播到克隆的方式将一些元数据附加到存储库refs。简单示例（一个git-notes克隆原型，它甚至没有将注释附加到任何其他 git 对象）：

即我创建了一个blob带有哈希的对象hash并引用它，refs/comments/just因此git fsck --unreachable不会抱怨它，git gc也永远不会prune成为对象。

但这当然是一个非常简单的例子，实际上我对更复杂的功能感兴趣。在那里，我的问题是，我可以“合法”做什么，我应该绝对避免做什么？

例如，SE 上的几篇帖子是关于用户必须从重复tree条目中恢复的。因此，一个“不要”就是“不要创建tree带有重复条目的”。另一个例子是“确保你的对象是可访问的，所以不会git prune删除它们”。还有什么？

我可以创建自定义对象类型吗？对树中的 blob 使用“无效”文件模式？我在哪里可以找到概述？或者我应该git-fsck手动检查 's source 以查看什么构成错误（以及哪些是可以忽略的）？

我对文件的实际内容如何存储在 .git 中感到困惑。

例如Version 1是 中的实际文本内容test.txt。当我将它提交（第一次提交）到 repo 时，git 为该文件返回一个 SHA-1，该文件位于.git\objects\0c\15af113a95643d7c244332b0e0b287184cd049.

当我在文本编辑器中打开文件15af113a95643d7c244332b0e0b287184cd049时，它都是垃圾，像这样

x+)JMU074f040031QÐKÏ,ÉLÏË/Je¨}ºõw[Éœ„ÇR­ ñ·Î}úyGª*±8#³¨,1%>9?¯$5¯D¯¤¢„áôÏ3%³þú>š~}Ž÷*ë²-¶ç¡êÊòR“KâKòãs+‹sô

但我不确定这个垃圾是代表文本的加密形式Version 1还是由 SHA-1 代表15af113a95643d7c244332b0e0b287184cd049。