Merge Conflict

Not an error.

A system reporting that it has reached a decision it has no basis to make.

Most of a merge is arithmetic

Common ancestor, two descendants. For each region: did one side change it, both, or neither?

One side changed it, the other didn’t: apply it. No preference expressed, nothing to weigh.

A three-way merge: an ancestor splits into versions A and B and rejoins. Regions only one side changed are applied automatically; the region both changed stops and is handed back.

The one hard case

Both sides changed the same region, differently.

Two candidate texts. No ancestor to defer to. No ground to prefer either.

<<<<<<< HEAD
the committee reviewed the findings
=======
the committee noted the findings
>>>>>>> revision

Not stylistic variants

Reviewed and noted make different claims about what the committee did.

One of them becomes what the record says happened.

Three properties the tooling conceals

  • Lossy: the discarded version goes nowhere a reader will find
  • Unattributed: the file records who merged, not who was overruled
  • Unexplained: no format has a field for why

A resolved merge looks exactly like text that was never contested.

Next week

Someone decided. The file reads as though there was never a question.

What entitled them?

Sources

  • A State-of-the-Art Survey on Software Merging Tom Mens, IEEE Transactions on Software Engineering 28(5), 2002, 449–462. Surveys merging from purely textual through syntactic to semantic techniques. The further up that ladder a tool climbs, the more it can combine. No rung reaches intent. dl.acm.org
  • A Formal Investigation of Diff3 Sanjeev Khanna, Keshav Kunal and Benjamin C. Pierce, FSTTCS 2007, LNCS 4855, 485–496. Takes the de facto standard merge algorithm and checks its intuitive properties. Several turn out to be false in general. cis.upenn.edu