I am working on merge conflicts tool[1], so this area is of interest to me. But I fail to see the points of the author. In the first example he gave, git will actually give you three blobs: our, their and ancestor. The ancestor should have the missing information from his example and using code diffs[2], you can see what happened at each blob. Essentially, his blob is a single view of the 3 blobs merged together. Could be useful on the terminal, but if you are using a visual tool, a 3-way diff is always better.

> merges never fail

I am not sure what never fail means here.

> Conflicts are informative, not blocking. The merge always produces a result.

What does this even mean? You merge first and review later? And then other contributor just build on top of your main branch as you decided you want to change your selection?

If you want a smarter merge conflict tool, the one I am enthusiastic about today is Mergiraf: https://codeberg.org/mergiraf/mergiraf

1: https://codeinput.com/products/merge-conflicts 2: https://codeinput.com/products/merge-conflicts/demo

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]