标签: diff3

最近我启用了diff3,现在解决冲突要容易得多.

以前在某些情况下,我必须检查日志,看看人们为什么这样做以及合并.但是使用diff3,信息会在一个地方显示出来

<<<<<<< HEAD
THIS IS USEFUL
||||||| merged common ancestors
This is useful
=======
This is really useful
>>>>>>> c2392943.....

由此我们可以很容易地看到结果应该是"这真的很有用"

我想知道diff3是否有任何缺点？为什么它不是git的默认行为？

我正在与merge.conflictStyleset进行合并diff3.通常,这会插入由四(4)组字符分隔的三(3)个部分.

合并的Git文档清楚地解释了这些符号对于简单案例的含义(如下所述).

常规diff3:

Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
|||||||
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

但是,我得到了一个更复杂的结果,有许多额外的行(见下文).我有一种感觉,这与我正在合并的提交的祖先中进行了大量合并这一事实有关,但我无法弄清楚额外的行是什么意思.我似乎也找不到这种行为的任何文档.

这是我得到的(编辑当然,以保护代码的身份).

(我试图合并的任何提交的代码中都没有冲突标记,所以这不是答案.)

<<<<<<< ours
||||||| base
<<<<<<< Temporary merge branch 1
||||||| merged common ancestors
        if (sendRedirect(result)) …

是否可以设置Git以便我可以在KDiff3中使用三向比较？

我有两个分支,它们太不同了,无法自动合并它们,我只需检查每个合并点,我认为最好的方法是检查分支我希望从其他分支的更改并说

git difftool HEAD_OF_OTHER_BRANCH -- .

然后在KDiff3中选择合并文件.在完成了我刚刚提交的文件之后.

我已将merge.conflictstyle和diff.conflictstyle设置为diff3,但KDiff3仍然以双向diff开头.这可能吗？我想如果Git也将共同祖先的哈希作为参数发送,这是可能的,但是它呢？

有讨论有关如何使用SVN和BC3做到这一点,但我无法找到Git和KDiff3什么.

我刚刚阅读了Git 2.35.0 的发行说明（尽管注释 2.35.1 已经可用）。

在这些发行说明中，我看到：

• 添加了“Zealous diff3”风格的合并冲突呈现。

我的问题：

1. 如何使 git diff / difftool 默认为“热心”差异演示文稿？
2. 与默认的差异呈现模式相比，使用它有哪些优点和缺点？

我正在尝试使用具有这样的标记的Linux diff命令创建一个diff文件(取自diff3手册页):

          <<<<<<< mine
          lines from mine
          =======
          lines from yours
          >>>>>>> yours        

这种格式对我来说非常直观,并且允许我轻松地修复vim中的合并冲突,当我尝试使用diff3合并三个文件(我的,你的和原始文件)时它很有用,但我想从普通差异中获得相同的格式.我希望这很简单,但我无法得到它.我已经尝试了大多数主要选项(-e,-ed等)甚至尝试创建--changed-group-format但是没有成功.

希望这很简单,我只是忽略了.

更新:

两个文件差异示例,添加了行,删除行和冲突行:

我读了一篇关于三向合并的文章(diff3).它给出了一个如何检测冲突的示例.例子是:

A=[1,4,5,2,3,6]
O=[1,2,3,4,5,6] <<< Origin
B=[1,2,4,5,3,6]

在第一次计算OA和OB之后的差异时:

A=[1,4,5,2,3,   ,6]
O=[1,   ,2,3,4,5,6] 

和

O=[1,2,3,4,5, ,6] 
B=[1,2, ,4,5,3,6]

之后diff3 parse:

A=[1,4,5,2,   3    ,6]
O=[1,   ,2, 3,4,5  ,6] <<< Origin
B=[1,   ,2, 4,5,3  ,6]

Run Code Online (Sandbox Code Playgroud)

在发现冲突后:

1
4
5
2
<<<<<<<<<A
3
|||||||O
3
4
5
=======
4
5
3
>>>>>>B
6

按照这种方法来检测冲突,我尝试一个简单的例子:最初我有文件:

a;
b;

我做了更新用户1更新"a;","a=0;" 用户2更新"b;","b=0;" 我得到这个结果:

xx
<<<<<<< A
int a=0;
int b;
||||||| O
int a;
int b;
=======
int a;
int b=0; …

因此，我是使用vimdiff的新手，但是我感觉有些错误。每当我尝试使用以下命令从远程存储库中选择更改时：

:diffg RE

我得到错误：

E93: More than one match for RE

不知道这来自哪里或如何解决。我很惊讶堆栈溢出似乎没有在任何地方发布此问题。在此先感谢任何可以提供帮助的人:)

语境

git mergemerge.conflictStyle考虑合并冲突情况下的设置。可能的值为merge（默认）和diff3。

我注意到diff3有时会产生更大的冲突（参见下面的示例）。我找到了这篇论文，它diff3非常详细地描述了该算法，但我找不到太多关于默认merge算法的信息。

问题

merge和算法之间的确切区别是什么diff3？默认merge算法到底是如何工作的？

例子

我有这些文件：

• 根据：

1
2
3

• 你的：

1
change1
change2
input1OnlyChange1
change3
change4
change5
change6
input1OnlyChange2
change7
change8
change9
2
3

• 他们的：

1
change1
change2
input2OnlyChange1
change3
change4
change5
change6
input2OnlyChange2
change7
change8
change9
2
3

我得到merge2 个冲突标记：

1
change1
change2
<<<<<<< HEAD
input1OnlyChange1
=======
input2OnlyChange1
>>>>>>> input2
change3
change4
change5
change6
<<<<<<< …