启用 git rerere 有什么缺点吗？

Question

我已经阅读了有关 git 的 rerere 功能的各种内容，并且正在考虑启用它。

git rerere 功能是一个隐藏的功能。该名称代表“重用记录的解决方案”，顾名思义，它允许您要求 Git 记住您是如何解决大块冲突的，以便下次遇到相同的冲突时， Git 可以自动为您解决它。

https://git-scm.com/book/en/ v2/Git-Tools-Rerere

但我还没有看到有人提到使用rerere时可能出现的任何问题。

我必须假设有一个缺点，或者它可能会默认启用。那么启用 rerere 有什么缺点吗？它会导致哪些原本不会发生的潜在问题？

Answer 1

如果您错误地进行了合并，则将其丢弃，然后再次进行“相同”合并，它将再次错误。不过，您可能会忘记记录的解决方案。来自文档：

git rerere 忘记

这将重置 rerere 在 中为当前冲突记录的冲突解决方案。

请小心在特定路径上使用它；你不想把所有记录下来的决心都毁掉。 （忘记没有参数已经已弃用以防止您这样做，除非您输入 git rerereforget . 来明确请求它。）

但如果您不想这样做，您很容易就会陷入困境将错误的合并放入您的历史记录中..

Answer 2

正如 JC Hamano 在他的文章中提到的“rerere 的乐趣”（我的粗体）

• Rerere 记得您选择如何解决冲突区域；
• Rerere 还会记住您如何在冲突区域之外进行润色以适应语义变化；
• 即使您合并的两个分支的内容与之前解决的分支的内容不同，Rerere 也可以重复使用之前的解决方案。

即使是长期使用 rerere 的人也常常没有注意到最后一点。

因此，如果您在过于广泛的内容上激活 rerere，您可能会因为最后一点而得到令人惊讶或混乱的合并解决方案。

---

另一个缺点是 rerere 要求您提供 GPG 签名的 PIN（如果您已激活 commit.gpgSign）。
Git 2.38（2022 年第 3 季度） 已修复此问题

Answer 3

我已经全局启用了 rerere。我真的没有注意到任何问题，而且它通常似乎让我的生活变得更轻松。

Answer 4

我精心挑选了一个仅包含二进制文件的提交（在 gitk 中）。 Cherrypick 由于冲突而失败（仔细想想这是很自然的），我解决了保留 Cherry Pick 的冲突。后来我惊讶地发现在另一个 rebase 分支中我的 dll 没有表现 - 只是发现它们没有作为（我推测）自动冲突解决方案被带入 rebase 中。所以这是我遇到的唯一一个（启用了 rerere ）遇到违反直觉（尽管我确信完全一致）行为的情况。

Answer 5

根据这个问题和答案，Rerere< /em> 不记录冲突文件中不存在的部分分辨率。可能发生这种情况的一种情况是在文件重构期间，其中某些行被提取并移动到另一个文件，并且冲突的提交随后会更改这些行。这种情况下的解决方案将涉及在新文件中进行更改。

示例

初始状态

文件 a：

const foo = [
    'line 1',
    'line 2',
    'line 3',
];
// ...
const str = foo.join("\n");

重构

新文件 b：

const foo = [
    'line 1',
    'line 2',
    'line 3',
];

重构文件 a：

// ...
const str = b.foo.join("\n")

冲突

在另一个文件中对 a 进行 更改分支：

const foo = [
    'line 1',
    'line 2',
    'new line',
    'line 3',
];
// ...
const str = foo.join("\n");

解决方案

解决方案按原样保留文件a 中重构的内容，并将新行添加到文件b 中。但请注意，Rerere 仅将解析重新应用于文件 a，因为它在初始解析期间发生了冲突，而文件 b 没有遇到任何冲突。最初发生冲突。