Pha*_*ham 27 git git-diff diff3
最近我启用了diff3,现在解决冲突要容易得多.
以前在某些情况下,我必须检查日志,看看人们为什么这样做以及合并.但是使用diff3,信息会在一个地方显示出来
<<<<<<< HEAD
THIS IS USEFUL
||||||| merged common ancestors
This is useful
=======
This is really useful
>>>>>>> c2392943.....
Run Code Online (Sandbox Code Playgroud)
由此我们可以很容易地看到结果应该是"这真的很有用"
我想知道diff3是否有任何缺点?为什么它不是git的默认行为?
Von*_*onC 30
对于其他读者(以及本文):
git有一个选项来显示
diff3
格式的合并冲突(默认情况下它只显示要合并的两个文件).您可以像这样启用它:
git config --global merge.conflictstyle diff3
Run Code Online (Sandbox Code Playgroud)
你不应该启用diff3样式,因为你经常需要祖先来确定正确的合并是什么.
这是在相当早期(2008年)推出的,我认为它不是默认值,因为默认的unix diff不会显示为3向差异.
正如在这个线程中提到的,如果你想在不设置配置的情况下运行这个命令,那么你可以轻松地在普通差异和diff3之间切换,这在一个特定的情况下是可能的:
如果索引中标记了冲突(即,在冲突的合并之后,但在将路径标记为已解决之前,您所处的状态),则可以执行以下操作:
git checkout --conflict=diff3 <path...>
Run Code Online (Sandbox Code Playgroud)
请注意,这实际上是将索引内容签出到工作树中,因此您可能对冲突的工作树副本所做的任何编辑都将被覆盖.
Von*_*onC 22
默认合并冲突风格的另一个竞争者:zdiff3
从 Git 2.35(2022 年第一季度)开始:添加了“ Zealous ”风格的合并冲突呈现。diff3
请参阅Elijah Newren ( )提交的 ddfc44a(2021 年 12 月 1 日)。\n请参阅Phillip Wood ( )的提交 4496526(2021 年 12 月 1 日)。\n (由Junio C Hamano 合并 -- --在提交 4ce498b中,2021 年 12 月 15 日)newren
phillipwood
gitster
\n\n\n
xdiff
:实现一个热心的 diff3,或“zdiff3”基于补丁作者:Uwe Kleine-K\xc3\xb6nig
\n
\n共同作者:Elijah Newren
\n签署人:Phillip Wood
\n签署人:Elijah Newren
\n\n“zdiff3”与普通的相同,
\ndiff3
只是它允许在冲突块的开始或结束时压缩历史两侧的共同线。
\n例如,以下diff3
冲突:Run Code Online (Sandbox Code Playgroud)\n1\n2\n3\n4\n<<<<<<\nA\nB\nC\nD\nE\n||||||\n5\n6\n======\nA\nX\nC\nY\nE\n>>>>>>\n7\n8\n9\n
两侧有公共线\'
\nA
\'、\'C
\'、\' \'。\n如果使用,则会出现以下冲突:E
zdiff3
Run Code Online (Sandbox Code Playgroud)\n1\n2\n3\n4\nA\n<<<<<<\nB\nC\nD\n||||||\n5\n6\n======\nX\nC\nY\n>>>>>>\nE\n7\n8\n9\n
请注意,公共行 \'
\nA
\' 和 \'E
\' 已移至冲突之外。与“合并”中的双向冲突不同
\nconflictStyle
,zdiff3
冲突不会分成多个冲突区域,以允许C
在冲突之外显示公共“\”行,因为zdiff3
也显示了基本版本和基本版本无法合理分割。另请注意,删除两侧共有的行可能会使冲突区域内的剩余文本与冲突区域内的基本文本匹配(例如,如果冲突在冲突的右侧
\ndiff3
有 \' \',则5 6 E
公共行“E
\”将被移到外面,并且底部和右侧的剩余冲突文本将是行“\”5
和“6
\”)。
\n这有可能让用户感到惊讶,并使他们认为不应该存在冲突,但肯定存在冲突,并且应该保留。
diff3
应该是默认的。它不仅对解决冲突有用,而且使解决冲突成为可能。使用(仅)默认的合并冲突样式来正确解决冲突实际上是不可能的。我建议每个人设置diff3
他们的全局选项。
git config --global merge.conflictStyle diff3
Run Code Online (Sandbox Code Playgroud)
为什么从字面上看是不可能的?考虑一个foo1
在特定源文件位置添加函数的分支
git config --global merge.conflictStyle diff3
Run Code Online (Sandbox Code Playgroud)
和另一个foo2
在同一位置添加功能的分支
def foo1():
print("foo1")
Run Code Online (Sandbox Code Playgroud)
如果我将一个重新建立在另一个上,我就会发生冲突。默认合并冲突样式将显示
++<<<<<<< HEAD
+def foo1():
+ print("foo1")
++=======
+ def foo2():
+ print("foo2")
++>>>>>>> Add foo2
Run Code Online (Sandbox Code Playgroud)
冲突标记告诉我什么?他们告诉我需要将foo1
和都添加foo2
到文件中,对吗?不幸的是没有!考虑这样一个文件foo1
和foo2
已经存在,且两个分支,它去掉了一个foo1
用来消除之一foo2
。如果我在另一个基础上重新建立一个结果是什么?默认合并冲突样式将显示
++<<<<<<< HEAD
+def foo1():
+ print("foo1")
++=======
+ def foo2():
+ print("foo2")
++>>>>>>> Remove foo1
Run Code Online (Sandbox Code Playgroud)
在默认冲突样式下,删除两个函数的情况与添加两个函数的情况完全没有区别(除了提交消息的文本只能作为提示)!因此,它不足以解决冲突。这可能解释了为什么解决冲突被视为一种黑暗艺术。 diff3
不仅使它成为可能,而且常常使它变得容易。
归档时间: |
|
查看次数: |
7336 次 |
最近记录: |