启用 git rerere 有什么缺点吗？

Are there any downsides to enabling git rerere?

提问by Ryan C. Thompson

I've read various things about git's rerere feature, and I'm considering enabling it. But I haven't seen anyone mention any possible problems that could arise while using it. I have to assume there is a downside, or it would probably be enabled by default. So is there any downside to enabling rerere? What potential problems can it cause that would not otherwise occur?

我已经阅读了有关 git 的 rerere 功能的各种内容，我正在考虑启用它。但是我没有看到任何人提到使用它时可能出现的任何问题。我必须假设有一个缺点，否则它可能会默认启用。那么启用 rerere 有什么缺点吗？它会导致哪些不会发生的潜在问题？

采纳答案by MatrixFrog

If you do a merge incorrectly, then discard it, then do the "same" merge again, it will be incorrect again. You can forget a recorded resolution, though. From the documentation:

如果你做一个不正确的合并，然后丢弃它，然后再次做“相同”的合并，它会再次不正确。不过，您可以忘记记录的分辨率。从文档：

git rerere forget <pathspec>

This resets the conflict resolutions which rerere has recorded for the current conflict in <pathspec>.

git rerere forget <pathspec>

这将重置 rerere 为当前冲突记录的冲突解决方案<pathspec>。

Be careful to use it on specific paths; you don't want to blow away all of your recorded resolutions everywhere. (forgetwith no arguments has been deprecatedto save you from doing this, unless you type git rerere forget .to explicitly request it.)

小心在特定路径上使用它；您不想到处吹走您录制的所有分辨率。（为了避免您这样做，不推荐使用forget无参数，除非您键入以明确请求它。）git rerere forget .

But if you don't think to do that, you could easily end up putting that incorrect merge into your history..

但是，如果您不认为这样做，则很容易最终将错误的合并放入您的历史记录中。

回答by VonC

As J. C. Hamano mentions in his article "Fun with rerere"

正如 JC Hamano 在他的文章“ Fun with rerere”中提到的

• Rerere remembers how you chose to resolve the conflicted regions;
• Rerere also remembers how you touched up outside the conflicted regions to adjust to semantic changes;
• Rerere can reuse previous resolution even though you were merging two branches with different contents than the one you resolved earlier.

Even people who have been using rerere for a long time often fail to notice the last point.

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

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

So if you activate rerereon too broad a content, you might end up with surprising or confusing merge resolution because of the last point.

因此，如果您rerere在太广泛的内容上激活，由于最后一点，您最终可能会得到令人惊讶或令人困惑的合并解决方案。

回答by Marnen Laibow-Koser

I've got rerere globally enabled. I really haven't noticed any problems, and it usually seems to make my life easier.

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

回答by Mr_and_Mrs_D

I cherry picked a commit (in gitk) that only contained a binary file. Cherrypick failed due to conflict (which coming to thing about it is natural) and I resolved the conflict keeping the cherry pick. I was surprised later to find in anotherrebased branch that my dlls did not behave - only to discover they were not carried into the rebase as (I speculate) automatic conflict resolution. So this is the only case I met (having rerere enabled) of running into counterintuitive (though I am sure perfectly consistent) behavior.

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