Mercurial合并策略与Git合并策略

The*_*eff 4 git merge mercurial

我已经使用git多年了,最近换成了一个项目的mercurial.在过去的6个月里,我已经学会了如何通过命令行很好地使用Mercurial.

这可能是我的想象,但在我看来,mercurial在合并时更糟糕,并导致更多冲突的文件.我会经常将默认分支合并到我的功能分支中,它有时会做一些非常时髦的事情,并且无法自动合并看起来应该在视觉上合并的文件 - IE在同一行上没有变化等.

我做了很多研究,看看合并算法可能有什么不同,运气很少.大多数文章都是人们关于git和mercurial如何工作的意见和信息,而没有太多关注合并算法本身以及差异的简单语言示例的上行/下行.

我总是使用良好的合并策略并通过树合并,并且永远不会进入默认(hg)/ master(git)分支而不首先合并到远程以确保没有冲突.

到目前为止,我在研究中发现的是:

1)Mercurial不能合并或有多个父母合并的问题.我不确定有人会在这种情况下结束,但也许这很常见？

这是真的？这会导致每天开发中更频繁地合并冲突吗？

2)Mercurial不支持章鱼合并,git就是这样做的.

对于章鱼合并,我说"谁在乎!",这不是必需品.

除此之外,似乎合并算法同样创建？是否可以更改合并算法？这有什么好文章吗？

如果您在k3diff,p4merge和meld之类的合并工具上发布信息,那么您就错过了重点 - 我想在冲突解决之前获得有关自动合并策略的信息.

感谢您提供有用的参考和/或信息!

tor*_*rek 10

1)Mercurial不能合并或有多个父母合并的问题.我不确定有人会在这种情况下结束,但也许这很常见？

这是真的？这会导致每天开发中更频繁地合并冲突吗？

不,这不是真的 - 至少如所声称的那样,这似乎有点无意义.

执行基于提交图的合并的根本问题与查找最低公共祖先或LCA有关.在树中,总有一个LCA,因此它是三向合并的明显输入:它是通常的基本提交,左侧/本地/ --ours提交,右侧/远程/ --theirs操作的基础.

但是,在提交DAG中,可能存在多个LCA节点.Mercurial对此的默认解决方案是任意选择一个或多个.Git的默认解决方案是选择所有这些并使用-s recursive策略合并它们.这种"内部"合并导致单个最终提交,然后Git将其用作合并基础.您可以覆盖它以执行Mercurial使用的相同操作-s resolve:或多或少地选择一个,并将其用作基础.

Mercurial有几个实验性的替代合并策略(参见,例如,BidMerge),但没有一个包含"开箱即用",与Git的四个-s策略不同.

多个合并基础主要发生在某人进行"纵横交错合并"时.请参阅Git中如何出现纵横交错合并？在某些工作流程中,这种情况永远不会发生,在实践中并不是那么常见.

2)Mercurial不支持章鱼合并,git就是这样做的.

对于章鱼合并,我说"谁在乎!",这不是必需品.

那是对的.可以使用一系列成对合并来模拟任何章鱼合并.不过,它们特别适合炫耀.:-)

除此之外,似乎合并算法同样创建？

不,因为Mercurial和Git使用不同的算法来跟踪文件名.这里的问题是这样的:一旦你有三个输入三路合并,谁说,文件path/to/f的基础是相同的文件path2/f2在左侧和/或path3/f3在右边？哪个文件(S),我们就要配对,或确定我喜欢叫它？

Mercurial对此的回答是通过清单和记录的目录操作(记录的重命名或副本)跟踪文件标识,而Git则通过内容匹配动态确定文件标识.但是,完全动态确定在计算上过于昂贵,因此Git作弊:如果两个文件在base-vs-left或base-vs-right中具有相同的路径,则这两个文件被标识为"相同"文件.这样只留下没有配对的路径名来动态识别.

还必须处理在最终结果中使用哪个路径名.Mercurial让你在merge命令运行时选择,而Git只是将所有名称填充到其索引中,允许后续的延迟名称选择.

但是,一旦适当地识别和命名,合并过程本身就是相同的:找出哪个方面改变了哪个文件.如果只有一方更改了文件,请使用该方的版本.否则,在三个输入上执行文件级别合并(Git 在内部将其称为低级别合并).这需要计算差异或跟随和组合各个变更集,Git和Mercurial都选择直接的"差异基础对尖端"方法.(由于Git总是存储快照,所以它就是这样强制的.Mercurial 有时存储快照,所以它也是强制性的.)但是它们的内部差异引擎也不相同,所以这也会产生一些不同的结果.