24

有没有办法在提交之前知道提交的哈希值？

4

3 回答 3

19

你有什么可能的理由需要这个？如果您正在考虑将提交的哈希值放入它自己的提交消息中，很抱歉告诉您，但这是不可能的（或者至少，在不破坏 SHA1 的情况下是不可能的）。提交消息是生成散列时使用的部分之一，因此任何修改消息的尝试都会更改散列。

在任何情况下，在提交之前找出提交的哈希与实际提交、写下哈希然后丢弃提交几乎没有区别（正如卡尔诺鲁姆在他的评论中所建议的那样）。原因是哈希是通过制作提交对象并通过 SHA1 传递来生成的。因此，为了在不提交的情况下找到散列，您基本上必须手动完成提交过程并对结果进行 SHA1，而无需实际将对象写入磁盘。这不仅不切实际，而且完全没有意义。

于 2013-01-08T04:43:44.283 回答
15

提交哈希取决于提交时间。

如果您在同一秒内使用相同的更改、相同的父级、相同的作者和提交消息进行 2 次提交，您将获得相同的哈希值。否则，哈希应该不同。

于 2013-01-08T05:46:20.403 回答
1

如果您只对提交的可预测引用感兴趣并且不关心完整的哈希，您可以在使用lucky-commit 提交任何您喜欢的内容后自定义短哈希（前 4 到 8 个字符） 。这也适用于 GPG 签名的提交。

注意事项：

  • 您在开始时修复的字符越多，花费的时间就越长，成倍增长。
  • 它必须在每次提交后运行
  • 它将为本地存储库中的每个提交进行重复提交。请参见下面的示例：
% git log --oneline --graph         
* 0000003 (HEAD -> master) Third commit
* 0000002 Second commit
* 0000001 First commit
% git log --oneline --graph --reflog
* 4ef3899 Third commit
| * 0000003 (HEAD -> master) Third commit
|/  
* 0000002 Second commit
| * d756f59 Second commit
|/  
* 0000001 First commit
* a1e6be7 First commit

Finding commit hash before making a commit is possible in theory, but requires in-depth knowledge of git's inner workings and then engineering a solution around it. For a brief overview you can read Git Magic Chapter 8 Secrets Revealed, sections on Blobs, Trees, and Commits.

于 2022-02-04T05:31:54.270 回答