Three-Way Merge¶
Version-control procedure — instantiates Reconciliation After Drift
Uses the common ancestor of two divergent versions to attribute each change to a side, auto-combining the non-overlapping ones and flagging only the true collisions.
Three-Way Merge reconciles two versions that diverged from a shared starting point by consulting that starting point — the common ancestor — as a third input. Its defining move is ancestor-based attribution: comparing each version to the base rather than to each other, so the procedure learns not merely that the two differ but who changed what. A change that only one side made is applied automatically; only where both sides changed the same region does the merge stop and declare a conflict. This is what separates a three-way merge from a naïve line-up of two files, which sees every difference as a possible conflict because it cannot tell an edit from the other side's untouched original. The output is a single combined version wherever the changes are independent, and an explicit, marked conflict wherever they are not.
Example¶
Two developers branch off the same config.yaml at commit a3f. Dana adds a timeout: 30 block to the top of the file; Ravi, independently, rewrites the logging section at the bottom and, in one line, bumps retries from 3 to 5. When their branches merge, a three-way merge compares each branch back to the a3f ancestor. Dana's new timeout block did not exist in the ancestor and Ravi never touched it — attributed cleanly to Dana, applied automatically. Ravi's logging rewrite touches lines Dana left at their ancestor state — attributed to Ravi, applied automatically. The retries line is the one collision: the ancestor said 3, and only Ravi changed it, so — because Dana left it untouched — that too merges cleanly to 5. Had Dana also set retries: 4, the ancestor's 3 versus two different new values would be flagged as a conflict with all three shown, and no guess made. The result is one merged config.yaml combining both developers' independent work, with a human asked to decide only where they genuinely collided.
How it works¶
- Fetch the merge base. Identify the most recent common ancestor of the two versions — the shared point from which they diverged.
- Attribute changes against the base. Diff each version to the ancestor, so every change is tagged to the side that made it and untouched regions are recognized as such.
- Combine the independent changes. Apply, under the merge policy, all changes made by only one side — these compose without loss.
- Mark the collisions. Where both sides changed the same region to different values, emit a conflict showing base, ours, and theirs, and leave it for resolution rather than choosing.
Tuning parameters¶
- Merge granularity — line, hunk, token, or structural (syntax-aware) comparison; finer or structure-aware granularity turns many would-be conflicts into clean merges but costs more to compute.
- Ancestor selection — which common ancestor is used when history has several (the criss-cross case); the choice changes what counts as a conflict.
- Whitespace and formatting sensitivity — whether reformatting-only changes count as edits; ignoring them cuts spurious conflicts but can mask a real one hidden in a reformat.
- Auto-combine boundary — how aggressively adjacent independent edits are merged versus treated as touching; looser boundaries merge more but raise the odds of a semantically coupled edit slipping through.
- Conflict marker style — two-way versus three-way (diff3) markers that also show the ancestor; showing the base makes conflicts far easier to resolve correctly.
When it helps, and when it misleads¶
Its strength is that the ancestor lets independent work combine without a human touching it, while narrowing the demand for judgment to the genuine collisions — the standard diff3-style reconciliation[n1] that lets many people edit a shared artifact in parallel and recombine with minimal friction. It fits source code, configuration, structured documents, and any versioned text with a retrievable common base.
Its failure mode is the clean-but-wrong merge: two edits on different regions combine flawlessly by text yet are logically one coupled decision — Dana renames a function while Ravi adds a call to its old name, each in untouched territory, so no conflict fires and the merged code is broken. Textual independence is not semantic independence, and a three-way merge only reasons about the former. The classic misuse is trusting a conflict-free auto-merge as if it were verified, or resolving conflicts by blindly taking one side to make the markers disappear. The guarding discipline is to treat a clean merge as unproven until a build or test — a separate verification step, not part of the merge — confirms it, and to resolve each real conflict by understanding both intents rather than picking a winner to silence the tool.
How it implements the components¶
comparison_rule— the ancestor-relative diff: comparing each version to the common base rather than to each other is the rule that attributes every change to a side.merge_policy— the structured combination of non-overlapping changes into one version, the rule for how independent edits are composed without either replacing the other wholesale.reconciled_state— the single merged version produced wherever changes are independent, with genuine collisions carried as explicit conflict markers rather than silently resolved.
It does NOT implement conflict_resolution_rule — deciding which side of a true collision wins is settled by an authority such as Source-of-Truth Table or a human reviewer; a three-way merge only *detects and combines. Nor does it build the reconciling-items schedule or run the arithmetic tie-out (difference_inventory, verification_check) of Ledger Reconciliation Workflow.*
Related¶
- Instantiates: Reconciliation After Drift — the ancestor-based repair path for two versions that diverged from a shared base.
- Sibling mechanisms: Ledger Reconciliation Workflow · Inventory Count Reconciliation · Custody Chain Reconciliation · Source-of-Truth Table · Audit Log Review · Data Diff and Merge Tool
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Three-Way Merge operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it uses the common ancestor of two divergent versions to attribute each change to a side, auto-combining the non-overlapping ones and flagging only the true collisions.
Independent corroboration: The frozen evidence defines Three-Way Merge as 'Uses the common ancestor of two divergent versions to attribute each change to a side, auto-combining the non-overlapping ones and flagging only the true collisions', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Three-Way Merge includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Three way merge derives most directly from computer science's software, data-system, and algorithmic tradition; its defining operation is to uses the common ancestor of two divergent versions to attribute each change to a side, auto-combining the non-overlapping ones and flagging only the true collisions.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: uses the common ancestor of two divergent versions to attribute each change to a side, auto-combining the non-overlapping ones and flagging only the true collisions.
- Security Studies & Intelligence Analysis — Security's adversarial analysis, integrity, and incident-response tradition provides a formative adjacent lineage for the same three way merge operation.
Review resolution: Both blind reviewers independently select computer_science as the primary historical origin for the concrete operation—Uses the common ancestor of two divergent versions to attribute each change to a side, auto-combining the non-overlapping ones and flagging only the true collisions. The queued differences concern alternate origin disagreement, origin mode disagreement, domain reach disagreement, encyclopedia synthesis disagreement, not the primary lineage. I retain every alternate that either reviewer explains, without a numeric cap, and choose origin_mode=cross_disciplinary_synthesis because the reviewers' combined evidence identifies material construction from multiple disciplines. domain_reach=universal records later portability rather than multiplying historical origins; confidence=high is the conservative shared evidentiary level, and encyclopedia_synthesis=true preserves either reviewer's affirmative synthesis finding.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
It is easy to conflate this with a Data Diff and Merge Tool: the tool is a packaged application that surfaces diffs and lets a person drive a merge, whereas a three-way merge is the attribution logic itself — the ancestor-based rule for deciding which changes combine and which collide. The tool typically runs this logic under the hood; the procedure is the algorithm it runs.
[n1] diff3 is the classic three-way merge algorithm — it compares two revisions against their common ancestor and reports, for each region, whether one side, both sides, or neither changed it. Its <<<<<<< ||||||| >>>>>>> conflict markers, showing ours / base / theirs, are the reason a three-way conflict is usually resolvable where a two-way one is only guessable. ↩