背景
我目前正在解决启用git rerere的 merge 冲突。 git status显示一条未 merge 的路径。当我查看文件时，没有<<<<<<< HEAD或>>>>>>> <SHA>标记标识冲突，这告诉我rerere已完成工作并根据我过去的处理方式解决了冲突。
我想确认rerere的决议是正确的。
我正在处理的 merge 过程非常复杂，涉及到多个参与Linux内核的远程操作。昨天，我对几个远程服务器进行了测试 merge ，目的是识别冲突，通知维护人员，然后丢弃生成的(肯定是损坏的)内核。这样做的时候，我做了几个粗心的冲突解决方案，只是继续前进到下一个 Remote ，并在完成所有冲突的路径后调用git rerere forget <pathspec>，包括我现在正在处理的冲突路径。由于我告诉rerere忘记了这条路，所以我不知道为什么它可以解决此问题，并且我担心它会应用我昨天所做的修复，而我不在乎结果是否正确。
问题
应用解决方案后，是否有任何方法可以查看重新解决了哪些冲突？
我想避免重新启动 merge ，因为这是一个漫长的过程，我们还没有完全自动化。另外，由于我昨天试图告诉rerere忘记这条路，但今天它仍然适用于解决方案，因此，如果我不知道为什么git rerere forget <pathspec>首先失败，我想我最终将处于同一位置。
相关问题
Undo a git rerere resolution that was done in a rebase Are there any downsides to enabling git rerere? git rerere forget <pathspec>
跟进说明/问题
我只是尝试输入不带pathspec的git rerere forget，我知道它已被弃用，但是如果我理解正确，应该重新输入，忘记所有分辨率。我重新运行了 merge ，它仍然对文件应用了分辨率。我也完全禁用了rerere并第三次运行了 merge ，因此我可以看到冲突，并且rerere确实在应用我昨天所做的三心二意的决议。为什么forget没有正确放弃我不想重用的分辨率？
最佳答案
您可以使用
git checkout -m path/to/file
然后用
git rerere
关于忘记麻烦，您是否在冲突仍在进行时忘记了？忘记适用于“中的当前冲突”