考虑这段历史：
E BUG: fix regression in <sha-1 of C>
|
D fixup! Do a thing
|
C Add a feature
|
B Do a thing
|
A Initial commit
是否有git rebase -i --autosquash的变体可以调整 E 的提交消息以匹配以下内容？
E' BUG: fix regression in <sha-1 of C'>
|
C' Add a feature
|
BD' Do a thing
|
A Initial commit
我真的想不出一种自动化的方法。 在交互式变基中，您可以将提交E标记为"改写"或"编辑"，并自行更改 SHA。 (我认为"编辑"可能更容易，这样您就可以在启动提交消息编辑器之前使用log找到要填写的正确 SHA。
更新
从评论中引入一些想法：如果您正在处理具有许多此类引用的大型历史记录的重写，例如使用手动消息编辑进行交互式变基是不现实的，那么设想解决方案要困难得多。
虽然您的问题似乎集中在rebase，但在评论中您提到您可能真的在考虑filter-branch。 (应该注意的是，这是一个非常不同的操作，因此几乎从来都不容易用一个代替另一个......
在任何情况下，最好的办法是在导致提交 SHA 值更改的同一操作中重写提交消息。 (如果你尝试在事后"这样做，那么重写提交X的消息将再次更改 SHA，不仅会更改X，还会更改通过父指针到达X的任何提交;因此您必须在这一点上跟踪/处理多个 ID 映射。
从理论上讲，你想要的是一个对SHA值进行sed类型搜索和替换的msg-filter;但问题是你在哪里得到"旧sha到新sha"的映射。
有一个 shell 函数map，Torek 表示至少在过滤器脚本中可以提供一些帮助。 (我找到的文档只确认这在执行commit-filter期间可用，但如果 torek 说其他过滤器可以看到它，那么我倾向于认为他是对的。问题是，如果确实没有记录，那么在未来的版本中是否会改变。 如果这让您担心，您可以将消息编辑硬塞进提交过滤器，也许......
因此，您可以编写一个脚本来查看旧的提交消息(如果您坚持使用msg-filter，则在 STDIN 上收到)并搜索可能的 SHA 值([0-9a-f] 中的 40 个字符的字符串)。找到可能的值后，它将调用map，如果map返回看起来像单个 SHA 值的内容，则编辑消息文本。 然后在 STDOUT 上返回编辑后的文本。 (但是：我相信这只有在您的提交消息中实际拥有完整的 40 个字符的 SHA 时才有效。 如果你缩写，那是另一罐蠕虫...
(请注意，map可以返回多个 SHA 值，但我发现的唯一情况是，如果您正在使用commit-filter做一些奇特的事情。