I3.11.2unstructured merge failuredesign

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

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/I3.11.2