标签: git-rerere

背景

我目前正在解决与启用git rerere的合并冲突.git status显示一条未合并的路径.当我查看文件时,没有<<<<<<< HEAD或>>>>>>> <SHA>标记识别冲突,这告诉我rerere已经完成了它的工作并根据我过去的方式解决了冲突.

我想确认rerere的决议是正确的.

我正在进行的合并过程非常复杂,涉及到Linux内核的多个遥控器.我昨天做了几个遥控器的测试合并,目的是识别冲突,通知维护者,然后丢弃最终的(肯定已损坏的)内核.在这样做的时候,我做了几个不小心的冲突解决方案,只是为了继续下一个遥控器,并且git rerere forget <pathspec>在我完成之后调用了所有冲突的路径,包括我正在处理的那个.因为我告诉rerere忘记这条路径,我不知道为什么它在这次运行中解决了任何问题,我担心它应用了我昨天做的修复,当时我不在乎结果是否正确.

问题

是否有任何方法可以查看在已经应用解决方案后重新解决的冲突？

我想避免重新启动合并,因为这是一个漫长的过程,我们还没有完全自动化.此外,因为我试图告诉rerere昨天忘记了这条路,但它今天仍然应用了一个解决方案,我想如果我不知道为什么git rerere forget <pathspec>先失败,我会最终处于相同的位置.

相关问题
撤消在rebase中完成的git rerere解决 方案< - 解决方案需要重新启动合并
启用git rerere是否有任何缺点？< - 只讨论git rerere forget <pathspec>

跟进注意/问题
我刚尝试输入git rerere forget没有pathspec,我知道这是不赞成的,但如果我理解正确,应该让rerere忘记所有的决议.我重新合并,它仍然对文件应用了一个解决方案.我也完全禁用了rerere并且第三次运行合并,所以我可以看到冲突,而rerere确实应用了我昨天所做的半心半意的决议.为什么forget不正确地丢弃我不想重用的解决方案？

Git 通常会根据以前的解决方案来解决冲突。

例子：

Auto-merging <file>
CONFLICT (content): Merge conflict in <file>
Resolved '<file>' using previous resolution.
Exit 1

1. Git 何时会根据之前的解决方案决定解决冲突？

2. 如何禁用基于先前分辨率的自动求解？

好的,这是我的问题."git rerere"比较两个文件的哈希来计算分辨率吗？也就是说,我有一个包含此标记的XML文件:

<number>12</number>

当我遇到冲突时,这个数字通常会改为13,14等,所以我坚持:

<<<<<<<
<number>12</number>
=======
<number>13</number>
>>>>>>>

即使数字与上次不同,是否可以重新自动解决此冲突？我总是希望它以这样的方式解决它,它需要更高的数字(例如上面的例子,13).因此,如果它记录了数字12和13的分辨率,它是否会解决与不同数字的冲突？我怀疑它不会,但不妨问.

git rerere 愉快地存储我的冲突解决方案，并在再次出现相同的冲突时自动应用它们。

但是，有时，我会遇到与我不希望自动合并的不同上下文的合并冲突。

有没有办法git rerere记住冲突解决方案，但需要明确调用git rerere来应用它们？

需要明确的是，我不是在寻找git rerere clearor git rerere forget，而是简单地，除非明确指示，否则不会自动解决合并冲突（如果它可以在申请前向我显示提议的解决方案，则奖励！）

（类似于这个问题，但有一些上下文和演示为什么rerere不是答案。）

对于给定的历史：

                /...o      origin/master
o...o...o...o...o...o...o  master
    \...o........../       topic

我有一个主题分支，我已将其合并到 master 中，并进行了一次额外的提交。同时，上游有人对 origin/master 进行了另一次提交，所以我不能再按原样推送我的 master。

我想将我的 master 重新绑定到 origin/master 而不更改主题上的提交 SHA，并且不会丢失已经在 master 上执行的冲突解决方案。（这是迄今为止我想要保留合并提交的最常见情况，所以我很惊讶这显然如此困难。）

与rerere启用，git rebase -p 几乎工程-在原来合并的任何冲突，它会记住我做了什么来解决这些问题并重新应用此（虽然它留下标记为冲突的，所以我必须要记住，纪念每一个的文件已经无需重新启动解决文件的冲突解决方案，这在 TortoiseGit 前端有点烦人）。但是，如果在合并提交中也修复了对文件的任何其他更改（例如，纯粹在合并中添加的行没有冲突，但由于其他地方的更改仍需要更正），这些都会丢失。

事情是这样的。在我对合并提交的（可能是有缺陷的）理解中，它们由两个（或更多）父项和一个唯一的变更集（用于存储冲突解决方案，以及在提交合并之前所做的任何其他更改或稍后修改为合并提交）组成。似乎rebase -p重新创建了合并提交，但完全丢弃了这个额外的变更集。

为什么它不重新应用原始合并提交中的变更集？这将使 rerere 变得多余并避免丢失这些额外的更改。如果需要人工确认，它可能会将受影响的文件标记为冲突，但在许多情况下，这种自动解决方案就完全足够了。

换句话说，标记上面的一些提交：

                /...N      origin/master
o...o...o...o...B...M...A  master
    \...T........../       topic

T - the commit on topic
B - the merge-base of origin/master and master
N - the new commit on origin/master
M - the merge between B and T
A …

git-rerere是我遇到的问题的精确解决方案......除了需要“学习”的合并已经执行并且重复起来并不简单。

我如何rerere以最少的手动干预来“教授”这些提交。

假设现有但有冲突的分支A和B被合并在一起以形成C已解决冲突的提交。然后我希望这样做：

• git checkout A
• git merge B
  • 当观察到冲突时合并暂停。
• git reset --soft C
  • 工作文件现在处于所需的最终状态 - 即冲突已“解决”。
• git merge --continue
  • rerere将更新的文件视为适当的分辨率，并“学习”此分辨率。

但该reset步骤不起作用:(

• --soft合并期间不允许重置。
• 重置--mixed核武器MERGE_HEAD（我假设通常会破坏 git 状态，这样合并就无法恢复）

编辑：

C通过预先检查并复制相关文件来手动“重置”文件是可行的，但由于存储库的庞大而复杂的性质，速度相当缓慢且乏味。

（很多项目位于单独的文件夹中，每个项目都有自己的 node_modules/packages 文件夹，这会消耗复制时间，除非我针对特定文件夹:( )

我希望有一些自动化的东西。＃乐观