【问题标题】:Git - diff3 Conflict Style - Temporary merge branchGit - diff3 冲突风格 - 临时合并分支
【发布时间】:2015-10-02 06:10:24
【问题描述】:

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

Git Documentation for Merge 清楚地解释了这些符号对于简单案例的含义(如下所述)。

常规 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))
            return new Result("redirect");

=======

        if ( result.getId() != null )
        {   
            object = new SomeObject(searchResult.getId()) ;
        }

        if (sendRedirect(result)){
            return new Result("redirect");
        }

>>>>>>> Temporary merge branch 2
=======

        if ( result.getId() != null )
        {   
            object = new SomeObject(searchResult.getId()) ;
        }

>>>>>>> theirs

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

【问题讨论】:

  • 在我的脑海中,我会说看起来有人在过去的某个时候提交了一个仍然带有合并冲突标记的文件。因此,这些合并标记现在被认为是当前合并中一个父级或另一个父级中实际文件的一部分...
  • @twalberg 我在问题中指出事实并非如此。
  • 对不起,我对“我尝试合并的任何提交的代码中没有冲突”进行了字面解释,但这并不排除分支中可能存在一些您正在尝试将 合并到...
  • 刚刚遇到这个问题(Hi Kalman)。我正在合并一个包含合并的分支,该分支已经解决了冲突解决方案。奇怪的是,没有更多的更改要合并,但 git 决定它需要合并。我的所有决议都保存在 rerere 中,所以我只是将合并重新合并为一个。

标签: git merge git-merge diff3


【解决方案1】:

您在这里拥有的(Temporary merge branch 1 和 2 相同)是由于 git 的“递归合并”方法:

            o->branch1 = "Temporary merge branch 1";
            o->branch2 = "Temporary merge branch 2";
            merge_recursive(o, merged_common_ancestors, iter->item,
                            NULL, &merged_common_ancestors);

merge-recursive.c,大约在 1940 行)。当提交图有多个合并库的候选者时,Git 将执行递归合并(有关更多信息,请参阅this blog post)。为了(过度?)简化一点,git 进行了内部递归合并,产生了合并冲突,然后进行了外部合并并遇到了另一个合并冲突。您看到的是外部合并冲突(ourstheirs),内部冲突显示为“基本”版本。

您可能会发现通过选择其他一些合并策略或使用替代差异算法(patienceminimalhistogram 算法与默认的myers)可以获得更好的结果。或者,您可能想暂时禁用diff3 样式,以便您根本看不到看到内部合并。

【讨论】:

  • 所以,你基本上必须像其中一些嵌套一样阅读它?我想这将有助于缩进一些符号以使其可视化。另外,有什么地方可以阅读这个吗?
  • 是(对嵌套部分);至于阅读它,请参阅该博客文章(这是我在快速搜索中找到的最好的 - 它专门用于 ClearCase,但想法是相同的)。
  • 感谢您的指导。但是,当我尝试使用“耐心”策略时,我收到消息,“可用的策略是:章鱼我们的递归解析子树。”您列出的策略有这些不同的名称吗?我想知道我需要安装一些东西吗?
  • @Sean:那些不是策略,它们是-X 参数(我喜欢称之为“扩展选项”)。例如,您可以使用git merge -X patience ... 将扩展的“耐心”选项传递给您选择的策略。
猜你喜欢
  • 1970-01-01
  • 2020-04-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-08-04
  • 2013-06-04
  • 1970-01-01
  • 2020-07-22
相关资源
最近更新 更多