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

问题描述

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

我尝试了 --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

这是一种错误吗?还是我做错了什么?

感谢任何帮助

解决方法

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

这是不可能的。哈希是提交的整个内容的加密校验和。更改消息中的单个位对校验和的影响与更改时间戳中的单个位相同:新提交获得一个新的、唯一的哈希 ID。这就是其他 Git 命令(在任何计算机上)识别这与原始提交相同提交的方式。如果散列没有改变,你将不能存储更新的提交,也不能将它发送到任何其他 Git。

这是 Git 存储模型核心的一个基本概念:哈希 ID 就是对象。该死的pigeonhole principle,每个比特流必须有自己唯一的哈希 ID。如果你能break the hash function,你就能break—or at least stymie—progress in the repository

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