Resolving a conflict requires enough context

What it is

The job of a conflict screen is not to get the user to click "confirm" fast, but to let them understand what collided before deciding. Presenting two versions for a binary pick is the bare minimum; what actually supports judgment is context: the common ancestor (what the region looked like before the collision), author and timestamp, the content surrounding the edit, and the reason for the change (commit message, comment). Without these, "keep mine or theirs" becomes a blind guess — the user cannot tell why the other person changed it, how long they worked, or which invisible dependencies moved. The test for a conflict interface: can someone not privy to the history make a decision comparable to the parties involved, using only what the screen provides?

Why it happens

A conflict is two individually reasonable intents landing on the same spot, and the resolver is missing at least one side's intent — usually the other person's. Deciding "which survives" is really reconstructing both intents and comparing them, and the raw material for that reconstruction is context. Without the ancestor, you see two end states but not what each party touched. Without surrounding content, you miss the entanglements (a one-word edit may correspond to a restructure three sections away). Without author and time, there is no one to ask and no situation to infer. Without a stated reason, motive must be reverse-engineered from wording, which is usually insufficient. The three-way view (yours, theirs, common ancestor) is standard in code-merge tooling precisely because it develops the film on "who changed what," offloading much of the intent-reconstruction cost from the user. When context runs short, the human default is to keep one's own version — one's own intent is the only one present — which biases conflict outcomes systematically toward whoever is more senior or more continuously present.

Studying it

• Paradigm: controlled experiments present the same conflicts with manipulated context completeness (two versions only / plus common ancestor / plus author and reason / full), measuring decision accuracy (agreement with expert rulings), decision time, and confidence; eye-tracking shows which information blocks users actually read; archival analysis of real repository merges relates context availability to resolution quality and rework.
• Variables: presence of context components (ancestor, author metadata, reason, surrounding span) as independents; decision quality, decision latency, and subsequent rework as dependents.
• Use in interface research: deciding which information blocks a conflict screen should show and how much surrounding content to expand, avoiding both starvation and overload.
• Methodological caveat: experimentally convenient conflicts (short synthetic text) make intent far less load-bearing than real ones (which routinely span dozens of lines and several entangled files). And "decided faster" is not "decided better" — both must be reported, or the study concludes, wrongly, that stripping context speeds things up.

Where it stops holding

What counts as sufficient context varies with artifact type: prose conflicts are mostly served by the two passages plus the ancestor; code conflicts additionally need type and reference information; design-file conflicts may need layer semantics. There is also a ceiling — dumping the entire history and every dependency onto the user amounts to outsourcing an archaeology project. Working practice is to show the frequently needed parts (ancestor, author, time, reason) by default and expand deeper on demand. Finally, no amount of context substitutes for talking to the other person; a conflict screen should keep a "contact the author" escape hatch rather than assume the information is self-sufficient.

Applying it

• Show all three parties by default: common ancestor, my change, their change, with difference highlighting.
• Annotate each version with author, timestamp, and stated reason (pull in commit messages or comments when they exist; leave blank rather than fabricate placeholders).
• Make surroundings expandable: default to several lines/sentences of context around the conflict, with one-click widening.
• Provide an "ask the author" entry point (comment, @-mention) that routes insufficient context to a human instead of forcing a blind pick.
• Verification: have a third party who did not write either version adjudicate historical conflicts through the interface and compare with the actual resolutions. Low agreement means the screen is under-informative; a run decided entirely by "keep mine" means the context never engaged.

Related

• Same group: V3.02.1 Silent overwrite is the most serious collaboration failure · V3.02.2 Conflicts must preserve both versions
• Nearby: V3.01 Concurrent Editing · V3.03 Version History · V6.04 Approvals and Review
• Search terms: conflict resolution context · three-way merge · common ancestor · merge conflict UI