【问题标题】:apparently same commits give different sha1, why?显然相同的提交给出不同的sha1,为什么?
【发布时间】:2011-08-03 16:51:00
【问题描述】:

在使用我的脚本从存储库重写子树历史后,我将其与在同一子树上执行git filter-branch ... 的内容进行了比较。我看到初始提交具有不同的 sha1,尽管我希望它们是相同的(结果是两个历史记录中的所有提交都具有不同的 sha1)。

在两次提交上执行git show --format=raw <commit-sha1> 会得到完全相同的输出(第一行除外,即commit <commit-sha1>,介绍了结果)。

目标文件完全不同,但由于它们是二进制文件,我无法找出根本原因。

假设所有 git 版本彼此一致,有 2 个不同的 sha1 可以解释什么?

谢谢

【问题讨论】:

  • 可能是更改的电子邮件、更改的提交日期或类似的元信息?

标签: git commit sha1


【解决方案1】:

Git 对提交哈希的输入包括元数据,例如树的 SHA1、父节点的 SHA1、提交者的姓名、电子邮件和提交日期,以及作者的姓名、电子邮件和提交日期。因此,当您重写历史记录时,提交者提交日期和树(因为您执行了 filter-branch)可能已经改变,因此您的提交的 SHA1 有所不同。

有关提交格式的更多信息,您可以使用git cat-file commit <sha>,或查找Git Objects section of the Git Book

【讨论】:

  • 报告了来自作者和提交者的所有树、父母、电子邮件、日期、姓名。同时,您使用git cat-file 的建议有所帮助,因为我在记录的cmets 中看到了一个额外的'\n',而我看不出与git show 有任何区别。我正在检查这个。
  • 我看到一些工具有时会在提交消息的末尾添加一个额外的空行(这样它就以一个空行结束)。也许这就是你的情况?
  • 我确认我的脚本错误地添加了换行符。我解决了这个问题,现在拥有相同的 sha1。谢谢西尔万。
猜你喜欢
  • 1970-01-01
  • 2012-03-31
  • 2020-05-13
  • 2012-06-22
  • 1970-01-01
  • 2014-11-30
  • 1970-01-01
  • 2021-02-15
  • 1970-01-01
相关资源
最近更新 更多