我已经使用git多年了,最近换了一个项目的mercurial。我在过去的6个月里通过命令行学会了如何使用Mercurial。
这可能是我的想象,但在我看来,mercurial在合并时更糟糕,并导致更多冲突的文件。我经常将默认分支合并到我的功能分支中,它有时会做很多时髦的事情,并且无法自动合并看起来应该在视觉上合并的文件--I.E。同一行没有变化等。
我已经做了相当多的研究,看看合并算法可能有什么不同,运气很少。大多数文章都是人们关于git和mercurial如何在幕后工作的意见和信息,而没有太多关注合并算法本身以及用差异的简单语言示例的上行/下行。
我总是使用良好的合并策略并通过树合并,并且永远不会进入默认(hg)/ master(git)分支而不首先合并到远程以确保没有冲突。
到目前为止,我在研究中发现的是:
1)Mercurial无法合并或与多个父母合并出现问题。我不确定某人是否会在这种情况下结束,但这可能很常见?
这是真的吗?这会在每天的开发中更频繁地引起合并冲突吗?
2)Mercurial并不支持章鱼合并,git就是这样做的。
对于章鱼合并,我说"谁在乎!",这不是必需品。
除此之外,合并算法似乎同样创建?是否可以更改合并算法?这篇文章有什么好文章吗?
如果您发布有关k3diff,p4merge和meld等合并工具的信息,那么您就错过了这一点 - 我想在冲突解决之前了解自动合并策略。
感谢您提供有用的参考资料和/或信息!
答案 0 :(得分:9)
1)Mercurial无法合并或与多个父母合并出现问题。我不确定某人是否会在这种情况下结束,但这可能很常见?
这是真的吗?这会在每天的开发中更频繁地引起合并冲突吗?
不,这不是真的 - 至少如声称的那样,这似乎有点无意义。
执行基于提交图的合并的基本问题与查找Lowest Common Ancestor or LCA有关。在树中,始终存在单个LCA,因此它是三向合并的明显输入:它是通常基本提交中的基础,左侧/ local / --ours
提交,右侧/远程/ --theirs
操作。
但是,在提交DAG中,可能存在多个LCA节点。 Mercurial的默认解决方案是随意选择一个或多个。 Git的默认解决方案是选择所有并使用-s recursive
策略合并它们。这"内部"合并导致单个最终提交,然后Git将其用作合并基础。您可以重写此操作以执行Mercurial使用-s resolve
执行的操作:使用或多或少任意选择一个,并将其用作基础。
Mercurial有几个实验性的替代合并策略(参见,例如BidMerge),但没有包含#34;开箱即用"与Git的四个-s
策略不同
多个合并基础主要发生在有人进行纵横交错合并时#34;请参阅How do criss-cross merges arise in Git?在某些工作流程中,这应该从不发生,并且在实践中并不是那么常见。
2)Mercurial不支持章鱼合并,git就是这样做的。
对于章鱼合并,我说"谁在乎!",这不是必需品。
那是对的。可以使用一系列成对合并来模拟任何章鱼合并。不过,它们特别适合炫耀。 : - )
除此之外,合并算法似乎是同等创造的?
不,因为Mercurial和Git使用不同的算法来跟踪文件名。这里的问题是:一旦你有三方合并的三个输入,谁说 base 中的文件path/to/f
是相同的文件左侧是path2/f2
,右侧是path3/f3
?我们应该将哪个文件配对,或者识别,因为我喜欢称之为
Mercurial对此的回答是通过清单和记录的目录操作(记录的重命名或副本)跟踪文件标识,而Git是通过动态确定文件标识内容匹配。但是,完全动态确定在计算上太昂贵了,所以Git作弊:如果两个文件在base-vs-left或base-vs-right中具有相同的路径,那么这两个文件被标识为&#34 ;同样的"文件。这样只留下没有配对的路径名来动态识别。
还必须处理在最终结果中使用哪个路径名。 Mercurial让你在merge命令运行时选择,而Git只是将所有名称填充到其索引中,允许后续的名称选择。
一旦适当地识别和命名,合并过程本身是相同的:找出哪个方面改变了哪个文件。如果只有一方更改了文件,请使用该方的版本。否则,在三个输入上进行文件级别合并(Git在内部将其称为低级别合并)。这需要计算差异或跟随和组合各个变更集,Git和Mercurial都选择直接的" diff基于尖端"方法。 (由于Git总是存储快照,所以它就是这样强制的.Mercurial 有时存储快照,所以它也是强制性的。)但是它们的内部差异引擎也不相同,但是,所以这也会产生一些不同的结果。
是否可以更改合并算法?这篇文章有什么好文章吗?
是的:Git有-s
个参数,而Mercurial在内部都是可插入的。
不,据我所知。我正在研究book,除了我这些天没有积极地工作,有不同的工作,而且它并不专门针对这些;但理论章节(至少有些接近完成)给出了适当的背景。