An example is, say you have a counter value. There’s two types of operations users can make - either reset the counter to some value or increment it. The counter was 20 and now it’s 25. Did the user set the counter to 25 or did they increment it 5 times? When there’s only one editor, it doesn’t matter - the result is 25 no matter what. But if two users both edited the value at the same time (the other user changed 20 to 30) now we have two different results based on the users intent. Either the new value be 35 (20+5+10) or we should pick one of the results (25 or 30) and just converge to that new value.

You can’t tell what the users intent was by simply diffing the old and new contents. The right approach is to capture the users intent directly from the software that they use to edit the value, and then preserve that intent through the synchronisation system.

This problem is also easy to reproduce with edits on lists / strings which contain repeated elements.

This kind of works but users don't always express their intent in their edit actions, either because no available edit action can fully capture the intent or because it was simpler to achieve the desired state in a different way.

Changing 999999999 to 1000000001, do you increment by two or re-type the whole number?

It is difficult to make users think in (invisible) state changes.

You see this in the preference for small commits.

Small commits are all about trying to preserve an explanation of change intent - but they're not ideal because you can end up doing a lot of incidental code just to keep them actually working if they get merged to master.

Whereas looking at the sum of a big commit, you just get a mess which doesn't tell you much of anything unless it's limited solely to inserting discrete blocks.

Whereas ideally what you really want to know is "there's 37 actions replacing the use of variable Y with a call to function X being passed Y" and the types are the same in all cases.