标签: git-hash

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

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

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

$ git cat-file blob 4716ca912495c805b94a88ef6dc3fb4aff46bf3c | sha1sum
de20247992af0f949ae8df4fa9a37e4a03d7063e  -

git如何计算文件哈希值？它是否在计算哈希值之前压缩内容？

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

到目前为止我提出的(我绝对不想依赖于提交消息)是检查HASH^2并查看我是否没有收到错误,是否有更好的方法？

我发现很难围绕Git如何创建完全独特的哈希,即使在前4个字符中也不允许相同的哈希.我只能使用前四个字符在Git Bash中调用提交.是否在算法中明确决定第一个字符是"超" - 唯一且不会与其他类似的哈希冲突,或者算法是否以相同的方式生成哈希的每个部分？

$ git describe --tags --long
test-1-g3c31c73
           \_ ???

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

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

hash=$(echo "Just a comment" | git hash-object -w --stdin)
git update-ref refs/comments/just $hash

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

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

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

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

如果 Git 提交哈希有多个与之关联的标签和/或多个分支的头部，是否有一种列出所有这些标签的好方法？

我已经通过选项看了git name-rev，git describe和git symbolic-ref，但还没有发现，似乎做我想做的任何选项。git name-rev令人沮丧的是，可以--tags选择只列出标签，但没有明显的机制来只列出分支（而且git name-rev对我来说似乎总是喜欢标签而不是分支）。

$ git checkout -b branch1
$ git checkout -b branch2
$ git tag tag1
$ git tag tag2
$ git name-rev HEAD
HEAD tags/tag1
$ git describe --all HEAD
HEAD tags/tag1
$ git symbolic-ref HEAD
refs/heads/branch2

要映射提交哈希所有的符号名，我将需要运行git tag --list和git branch --all --list，然后运行git rev-parse在所有的结果？

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

例如，Version 1中的实际文本内容test.txt。当我提交（第一次提交）到仓库时，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。

我假设 git commit hash (5743a31610d38064af35573b91e3bbe39d808b9b) 将始终映射到 0 或 1 git 分支？有没有可靠的方法来跟踪创建 git commit 时的分支名称？据我所知，git 分支是一个指向提交的指针，给定一个提交，我们能否可靠地指向一个分支（如果该分支仍然存在）？

上下文：我正在创建一些 devops 部署更改日志，以便我们可以跟踪我们更改的内容 - 我想知道是否值得命名已发布的 git 分支，或者只是将 git commit 哈希放在那里，我们可以反转如果我们真的想要查找分支名称？

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

我正在审查的存储库的特定状态可能绑定到git标记和提交哈希.众所周知,git标签的内容很容易改变.因此,再次下载源代码并基于版本标记信任它绝对不安全.

我的问题是:在下载新的源代码下载时,我是否可以相信,如果我根据它的完整提交哈希签出特定提交,那么这与我之前审查过的代码完全相同？

这个问题的焦点不在于完全发生sha1碰撞的可能性(因为碰撞比计算特定的sha1散列更容易计算 - 有希望 - 目前几乎不可能？),但是是否每个每个文件都是此sha1 sum的一部分,因此更改将始终触发不同的哈希.

为什么git SHA-1为具有不同名称和不同位置的文件分配相同的内容虽然内容相同？

100644 43efcd84207788e5289ee23a9ce95d9f43b13d9a 0 dir1/dir1_d2/dir1_d2_f1.txt 100644 43efcd84207788e5289ee23a9ce95d9f43b13d9a 0 test.txt

显示文件内容:

$ git cat-file -p 43efcd84207788e5289ee23a9ce95d9f43b13d9a Line 1

谢谢

我想获取主分支的所有提交哈希 ID。但是，使用以下命令时，只有最新的提交 ID 与结果匹配。旧的提交哈希 ID 不属于 master 分支。有没有其他方法可以获取仅属于 master 分支的提交哈希 ID？

git rev-parse origin/master --all