Free text generally cannot be merged by the system
Aliases: prose conflict · paragraph merge · three-way text
What it is
A paragraph of prose, a mail body, a note — both sides changed the meaning, and the system has no reliable way to stitch “the sentence both would own”. Unstructured content usually cannot be auto-merged. Character-level three-way merge can sometimes stack non-overlapping patches; once the patches fight semantically — the same sentence rewritten in two tones, the same argument deleted and strengthened — what stacks is a sentence nobody wanted. Stop as a conflict. Do not hand over a fake synthesis.
This is the other face of field-level merge: cells can merge, paragraphs often cannot. Do not count prose into the success rate under “we auto-merge documents”.
Why it happens
Auto-merge wants commutative patches. A structured field’s patch is “write due date as D”; two assignments on different keys commute. A free-text patch is “insert three characters at offset 40 / delete sentence 2”. Offsets break under the other side’s edit; even if operational transformation or a CRDT keeps characters from vanishing, what is guaranteed is characters, not a sentence that still reads as written by a person. Both sides change the subject of the same sentence; the transformed result may be two subjects in a row, grammatical, meaning wrecked.
Detecting semantic conflict is costlier than detecting character conflict, and has no stable truth value. So an honest system uses a conservative rule on text fields: merge when patches do not overlap, mark conflict and keep both originals when they do. An aggressive rule (always transform until one text comes out) raises the “no-conflict rate” at the cost of silent sentence-making. Sentence-making is harder to spot than a conflict, because the interface holds one fluent false body.
Where it stops holding
Orthogonal formatting on the same stretch (one person bold, the other a space that is not a punctuation change) can sometimes merge, if format and characters are stored apart. Code, tables, Markdown headings are sometimes more structured than prose and can merge by block; the prose inside the block still walks this leaf. Extremely short fields (a one-word tag, a number stored as string) assign as fields; do not treat them as prose. Machine-translated or spell-corrected text still looks like prose and still merges as text; origin-machine is not a licence to auto-pick a side. Legal contracts and copy that will be published carry more risk than an internal draft: the outward version must go through a human eye even if patches look disjoint.
Applying it
- Default on prose, notes, mail bodies: disjoint patches may merge; overlap is conflict and both originals stay. Do not run aggressive transform for a green dot.
- On conflict, show the two originals, not one “merged” sentence that makes people guess which words the machine stitched.
- Split success stats for “document auto-merged”: field success and text success reported apart, so a high field rate cannot hide text.
- How to check: two people change the same sentence into opposite meanings (one affirmative, one negative). After sync, a grammatical sentence neither wrote means auto-merge overreached. Then change two adjacent but non-overlapping sentences: auto-merge may apply. Contrast a card where only date and title changed: that is not this leaf’s text range, and must not be used to claim “text merges too”.
Related
- Same group: I3.11.1 Field-level merge shrinks what humans have to resolve · I3.11.3 Finer merge grains win more automatic merges and cost more complexity · I3.11.4 A merge UI must show where each difference came from, not only the result
- Nearby: I3.04 Sync conflicts · I3.10 Offline and local-first
- Search terms:
unstructured merge·three-way merge·prose conflict