2013-03-12 58 views
2

ORIGINAL:git合并会出错?

"<tasks>" 
+ " <exec command="ls">" 
+ " <runif status="failed" />" 
+ " </exec>" 
+ " <exec command="ls">" 
+ " <runif status="failed" />" 
+ " </exec>" 
+ "</tasks>"; 

MODIFICATION_1:

"<tasks>" 
+ " <exec command="ls">" 
+ " <runif status="failed" />" 
+ " </exec>" 
+ "</tasks>"; 

MODIFICATION_2:

"<tasks>" 
+ " <exec command="ls">" 
+ " <runif status="passed" />" 
+ " </exec>" 
+ " <exec command="ls">" 
+ " <runif status="failed" />" 
+ " </exec>" 
+ "</tasks>"; 

结果:

"<tasks>" 
+ " <exec command="ls">" 
+ " <runif status="passed" />" 
+ " </exec>" 
+ "</tasks>"; 

EXPECTED_RESULT:

"<tasks>" 
+ " <exec command="ls">" 
+ " <runif status="failed" />" 
+ " </exec>" 
+ "</tasks>"; 

在文件中的原始内容ORIGINAL

有人砍一个分支在这一点上和编辑ORIGINALMODIFICATION_2。上master有人改变ORIGINALMODIFICATION_1(改变第一<exec>节点从failedpassed

虽然。 (删除第一<exec>节点)

当合并分支到主变化是像RESULT(在分支的改变被施加到所述第二<exec>节点的代替第一被删除!),而不是产生EXPECTED_RESULT或导致合并冲突!

这是预期的行为?有人能解释为什么吗?

回答

2

这里的问题是,两个<exec>节点在ORIGINAL中是相同的。因此,MODIFICATION_1的删除是不明确的(它可能是第一个或第二个实例),并且合并算法实际上设法应用两个更改而没有任何重叠,因此不会导致合并冲突。

+0

完美的感谢:) – Srinivas 2013-03-12 11:49:43

+0

嗯,这听起来像它按顺序应用补丁,而不是使用3路合并? – 2014-02-12 23:05:22