[theK]

Isnt that a bit dangerous in its own? If the merge process can complete without conflicts being resolved, doesnt it just push the Problem down the road? All of a sudden you have to deal with failing CI or ghost features that involve multiple people where actually you just should has solved you conflict locally at merge time.

[furyofantares]

The tooling can force resolution at any step desired.

[theK]

What's the point of options when there only is one correct answer?

[furyofantares]

The conflict is no longer an ephemeral part of the merge that only ever lives as markup in the source files and is stomped by the resolution that's picked, but instead a part of history.

I think it is also not true that there's only one correct answer, although I don't know how valuable this is.

For committing let's say yes, only one correct answer. Say the tool doesn't let you commit after you've merged without resolving conflicts.

But continuing to work locally you may want to put off resolving the conflict temporarily. Like person A changed the support email to [e-mail] and person B changed it to [e-mail] - obviously some wires go crossed and I will have to talk to A or B before committing the merge and pushing, but I can also go ahead and test the rest of the merge just fine.

And heck, maybe even committing after merging is fine but pushing requires resolving. Then I can continue working and committing locally on whatever else I was working on, and I'll only resolve it if I need to push. Which may mean I never need to resolve it, because A or B resolve it and push first.

[shaftway]

> The conflict is no longer an ephemeral part of the merge that only ever lives as markup in the source files and is stomped by the resolution that's picked, but instead a part of history.

How is this different than having a merge commit?