2 ms·
Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while.
by HWR_14 4y ago
Wait, avoiding 3-way merges and instead only allowing 2-way merges has been on my list of "advantages of Mercurial that are sadly lost to git" list for a while. Can you expand on what you're saying?
- jdmichal 4y agoThree-way merge might not be the correct term. I mean it as in the three versions being "original", "version-a", and "version-b". Original is the most recent common ancestor of version-a and version-b. So the system can generate clean diffs based on that original version during the merge. I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
- HWR_14 4y agoAh, that's a standard merge but a 3-way diff. Many DVCSs have that (including Mercurial). A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it. But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.