问题标签 [diff3]

我有一个基本源文件base.hs，我使用它来创建同一程序（、、、）的不同foo.hs扩展bar.hs版本baz.hs。现在我想为每个修改版本创建一个补丁文件，但补丁应该累积以获得一个包含所有扩展的程序。

基础.hs

foo.hs（注意它基本上是同一个文件）

bar.hs

baz.hs

=>

扩展的.hs

差异+补丁？

我知道diff和patch实用程序，但问题是如果我应用多个补丁，它们会相互抵消（因此我会得到baz.hs）。

不工作

综合吗？

我也知道，combinediff但这仅在按顺序应用补丁时才有效，因此我需要从base_foo.hs.

差异3？

Diff + patch - Sum 而不是 replace是指diff3实用程序（patchutils包），但我似乎没有使所需的行为正常工作，而且我不知道这对多个补丁有何帮助。

不工作

（这里的想法是结合来自空文件的差异）

不工作

（显然它会产生一个包含所有三个版本的大冲突文件）

杂项？

我也有使用 git 等 SCM 的合并工具的想法，但显然它们只能用于提交，但我的文件不在版本控制中。

我目前的解决方案是通过插入代码片段，perl -pi -e但这相当费力且容易出错。

我有一个关于可能的 VCS 合并的理论问题。我知道许多 VCS 使用 3 个修订合并，即共同祖先、“我的”和“您的”修订。我知道它们是如何工作的。

我考虑过另一种替代方法，递归修订合并，在 Google 中没有找到。“你找到了美国！” 你可能认为。我知道 Git 使用递归合并。但是 Git 使用递归合并的原因是交叉合并

我说的是正常情况，非交叉合并。

例如，我们有一个共同的祖先 A 和分支 1 和 2。

如前所述，A 是共同祖先，因此它是 B 和 B' 的父级。

我们希望将 G 和 G' 合并到分支 1。Git 和 Mercurial 使用的常用方式是 diff3：

这将仅通过计算 3 个版本来计算合并，即 O(1)。

我想到的替代算法是 O(n)：

1. 首先将最接近的修订合并到祖先。

2. 将结果与分支 1 的下一个最接近的版本合并

3. 将结果与分支 2 中的下一个最接近的版本合并（如果保留）

4. 如果分支 1 中仍有任何修订，则重复（循环）到步骤 2。

在上面的示例中，它看起来像：

1. 合并 B 和 B'

2. 将结果与 C 合并

3. 将结果与 C' 合并

4. 将结果与 D 合并

5. 等等...

我无法解决的问题是 - 我的方式是否比传统的 3 修订版合并更安全、更准确（在非交叉合并中）？

我的方式能避免传统方式引起的冲突吗？

我的方式能创造出传统方式不会引起的新冲突吗？

我的方式冲突不是“真正的”冲突吗？（传统方式不会导致）

在 Git 中，标准的合并算法可以让你比较两个分支中文件的最终状态，这意味着我必须记住或猜测两个分支中导致该点的更改是什么。

通过显示共同的祖先，在 .gitconfig 中设置 merge conflictstyle=diff3 会有所帮助。但是，我仍然必须在脑海中进行差异化——即扫描不同的部分以找出祖先和分支 A 之间以及祖先和分支 B 之间的变化，然后最后将两者应用于祖先，或者应用一个分支对另一个的更改。

有没有工具可以为我做到这一点？我希望能够将一个分支中发生的更改与另一个分支中发生的更改进行比较。理想情况下，该工具还会向我显示我正在合并的更改的提交消息，这样我就不必猜测意图。

我正在尝试以这种方式使用 diff3

diff3 选项...我的旧的

我的问题是我可能无法使用它，因为我所有的 3 个文件都包含一个“破折号”。手册中提到： 这三个文件名中最多有一个可能是“-”，它告诉 diff3 读取该文件的标准输入。

所以我可能必须在运行 diff3 之前重命名文件名。

如果您知道更好的解决方案或解决方法，请告诉我。谢谢！

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

以前在某些情况下，我必须检查日志以了解人们为什么这样做和那样进行合并。但是使用 diff3 信息将全部显示在一个地方

从中我们可以很容易地看到结果应该是“这真的很有用”

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

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

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

常规 diff3：

但是，我得到了一个更复杂的结果，其中包含许多额外的行（见下文）。我有一种感觉，这与我在当前正在合并的提交的祖先中进行了多次合并这一事实有关，但我无法弄清楚额外行的含义。我似乎也找不到任何有关此行为的文档。

这是我得到的（当然是经过编辑的，以保护代码的身份）。

（我试图合并的任何提交的代码中都没有冲突标记，所以这不是答案。）

我相信这个问题是在问同样的问题，但答案并没有解释它与 diff3 有关的任何其他内容，提问者已经在标题中指出这是他/她熟悉的东西。我尝试编辑该问题两次，但都被拒绝了，所以我再问一次。

我有一些外部 mydiff3.exe，处理文本和二进制文件。

我的 svn 命令行是

这适用于文本文件（通过更新过程为每个冲突文件调用 svn 调用 mydiff3.exe），但对于二进制文件，svn 跳过 mydiff3.exe 并显示内部命令行菜单。

如何告诉 svn 接受--diff3-cmd mydiff3.exe二进制文件？

RTFM（来自 svn 红皮书的diff3-cmd和外部工具）没有帮助。

UPD：有人提到行为取决于 mime 类型 - 但不清楚在哪里配置它。

我正在尝试实现 diff3 算法，目前停留在块创建阶段。我已经知道如何在原始文件和“其他”文件之间获取 LCS，以及如何在原始文件和“我的”文件之间获取 LCS。需要执行哪些步骤来获取块？

我正在编写一个程序，该程序将使用自己的二进制格式来存储数据。

我想让某种形式的版本控制成为可能，至少两个不同的人应该能够对文件进行更改，然后合并这些更改。

由于 git 似乎是一个非常常见且非常强大的版本控制系统，所以我想知道是否可以使用它。我只有 git 的基本知识（pull add commit push），但我知道它有更高级的功能。我想了解我是否可以实现一些基本功能并免费获得所有高级功能。

所以用例是每个项目都由一个单独的二进制文件组成，而 git 必须能够使用它。

我一直在寻找并且明白我必须编写一个自定义合并工具？我的理解正确吗？

我也知道三路合并是由 diff3 程序完成的，或者至少 git 嵌入了一些功能。我必须编写它的自定义版本吗？甚至可以将它与git一起使用吗？是否需要重新编译git？

git 还将提交存储为更改以节省空间。它使用 diff 吗？有可能更换吗？git需要重新编译吗？
我还需要实现其他类型的功能吗？
我最初的计划是为项目使用单个文件，但每个项目都由独立的子项目组成，这些子项目将独立合并。通过将项目存储为每个子项目的不同文件，我会获得什么吗？

是否有一些关于 diff 、 diff3 和 mergetool 必须符合的接口的好的文档？这些可以用哪些语言编写？

我很困惑，因为每个人似乎都对从版本控制中消除二进制文件感兴趣，而且显然没有人想在它们上使用 git。这是个坏主意吗？我觉得以某种方式合并有意义的任何类型的数据都应该是版本控制的。

我正在尝试在 wiki 上维护一个项目的多个翻译。wiki 不支持翻译，但我可以使用文本文件导入/导出。所以为了简单起见，让我们认为文档中的每个文件都是一个简单的文本文件。

它是这样的：

1. 我用英文写维基文档。
2. 我下载了它（希望有一个工具为我做这件事）。
3. 新文件被复制到其他翻译的目录中（它是新的，所以还没有翻译）。
4. 翻译者用他/她自己的语言翻译新的 wiki 页面。那时它还在磁盘上，仍然在一个 txt 文件中。
5. 或者，翻译人员将新翻译的文件上传到网络上。

到现在为止还挺好。

6. 我开发了一项新功能并修改了英文 wiki 页面。
7. 我下载它。
8. 我更新了翻译版本……等等，它已经存在了，我不能只写文件来删除翻译者在第 4 步所做的一切！

所以我想有一种方法来创建一个部分翻译的文件，该文件将考虑到：

1. 文件翻译时的文件（英文）。
2. 同一文件在同一时刻的文件（以任何语言）。
3. 我新修改的文​​件（英文）。

它看起来像是 diff3 的一个很好的用例。但是 diff3 并不真正喜欢处理变化很大的文件。诚然，两个英文版本都可以比较，但翻译版本相差太大，处处产生冲突。

我的翻译方法可能有点奇怪，我试图寻找其他策略，但它已经淹没在商业替代方案中，如果我能提供帮助，这显然不是我的首选。

我希望我的解释是有帮助的。如果我可以指定更多，请不要犹豫。