“Contents conflict” is unclear to users, replace with “kind conflict” and “status conflict”

[Andrew Bennetts]

“Contents conflict” regularly confuses users, that don't understand what it means or how it differs from common (i.e. “text”) conflicts.

I think it'd be clearer to label them “status conflicts” (for cases such as modified vs. deleted, and added vs. renamed to the same path) and “kind conflicts” (for cases like one side changing a directory to a file, the other changing it to a symlink; or for kind change vs. a file modified change). I think these terms are still consistent with our internal model, and consistent with terminology we use elsewhere in our UI and docs.

A less ambitious change proposed by vila is to rename “contents conflict” to “tree shape conflict”. I think that would be an incremental improvement, but not as good as “status conflict” and “kind conflict”.

[Vincent Ladeuil (vila)]

+1

The actual 'content conflict' reflects the implementation, from a user point of view, the conflicts should be refined into more focused types which will make them easier to understand.

The main issue in adding new conflict types is backward compatibility but considering that the file is short-lived we may just want to *not* support upgrades or give the alternative: bzr revert or delete checkout/conflicts + commit.