git-filter-repo 回调提交或回调消息和 --preserve-commit-hashes 不起作用？

Question

我正在尝试更新提交消息，但同时保持相同的哈希值。

我尝试了 --message-callback 和 --commit-callback 这两个选项，但无论我选择哪一个，它都会生成新的哈希值。我是这样做的：

python3 git-filter-repo.py --preserve-commit-hashes --message-callback (or --commit-callback) '
if b"blabla" not in message:
    message = b"MyMessage " + message
return message' --force

这是一种错误吗？或者我做了一些完全错误的事情？

任何帮助表示赞赏

Answer 1

\n

我正在尝试更新提交消息，但同时保持相同的哈希值。

\n

\n

这不可能。哈希是提交的全部内容的加密校验和。更改消息中的单个位与更改时间戳中的单个位对校验和具有相同的根本影响：新提交将获得一个新的、唯一的哈希 ID。这就是其他 Git 命令（在任何计算机上）识别这与原始提交不同的提交的方式。如果哈希值没有更改，您将无法存储更新的提交，也无法将其发送到任何其他 Git。

\n

这是 Git 存储模型核心的一个基本概念：哈希 ID就是对象。该死的鸽子原理，每个比特流都必须有自己唯一的哈希 ID。如果你能破坏哈希函数，你就能破坏\xe2\x80\x94或者至少阻碍\xe2\x80\x94在存储库中的进展。

\n

（该--preserve-commit-hashes选项使内置的默认消息重写选项不查找类似于提交哈希 ID 的模式，而是在 filter-repo 生成的转换表中查找它们，然后使用结果。这与您想要的相反在一个存储库中，广泛使用了git cherry-pick -x，其中每个精挑细选的提交都会说明它是先前提交H的精挑细选，用于某些哈希。filter-repo 程序尝试确保首先处理较早的提交，然后在后续提交中替换过时的哈希 ID。我不知道这在实践中效果如何：目标很明显，但细节变得相当棘手。我不完全确定为什么这个选项存在，但是如果您正在进行历史重写，并且某些类似于提交哈希但实际上不是提交哈希的内容正在被损坏，这可能就是您使用此选项的原因。）

\n