How can two changes merge with no conflict and still leave the system broken?

## What a clean merge actually guarantees A clean merge guarantees exactly one thing: no region of any file was changed differently on both sides. That is a statement about text. It is not a statement about behaviour, about types, about invariants, or about whether the result even builds. A **semantic conflict** is the gap between those two things — two changes that are textually independent and logically incompatible. Because they never touch the same region, there is nothing for the merge to report, and the first sign of trouble arrives later: a failed build, a failed test, or, worst of all, output that is quietly wrong. ## The shapes it takes | One side does this | The other side does this | Why it merges clean | |---|---|---| | renames a concept everywhere it exists | adds a new use of the old name | the new use is in a file the rename never saw | | changes the unit or scale of a value | writes a caller passing the old unit | different files, no overlapping region | | tightens an invariant on entry to a routine | adds a path that enters without satisfying it | the new path is new text, not changed text | | deletes a routine believed unused | adds the first real caller of it | one deletion, one addition, no shared region | | changes a shared configuration default | adds code relying on the previous default | configuration and code live apart | The common structure is worth naming out loud in an interview: **a semantic conflict is a contradiction between a change to a contract and a change that depends on that contract, located in different places.** Splitting work by file or by module makes textual conflicts rarer and does nothing at all to this class — arguably it makes it more likely, because the two authors never see each other's text. ## Why no merge algorithm can catch it To report this, the algorithm would have to know what the merged program *means*: which values flow where, what a unit is, which invariants hold. That is program analysis, not text reconciliation, and it is undecidable in the general case for anything expressive enough to be useful. A merge implementation deliberately stays in the text world, where its guarantees are exact and cheap. Expecting a better merge tool to solve this is the most common wrong answer to this question. Type checking narrows one slice of it — a renamed symbol with a stale caller usually fails to build — which is precisely why the failures that survive are the ones where both versions are perfectly well-formed and only the meaning changed. ## What actually catches it 1. **Build and test the merged content itself.** Neither side's own passing run says anything about the combination; the merged result is code that has never been executed by anyone. 2. **Run that check automatically, on the merged content, before it reaches the shared line.** A pipeline that tests each side in isolation and then records the merge is testing two things nobody is going to ship. 3. **Integrate frequently in both directions.** The window in which contradictory changes can be made is exactly the time the two lines are apart; halving that time halves the exposure. 4. **Say contract changes out loud.** A message announcing that a meaning, unit or default has changed reaches the person about to depend on the old one; a merge algorithm never will. 5. **Review the merged result, not just the two diffs.** Both diffs can be individually impeccable. ## A worked case A university admissions system ranks applicants from a scoring routine. A second team, working in another timezone, changes that routine to emit a normalised score between 0 and 1 instead of raw points, and updates all 14 call sites they can see. Overnight, the home team adds a new eligibility path that reads the score and compares it against a raw threshold of 62 — code written against the meaning that held when their work began. The two changes touch 31 files between them and share none. The merge is clean, both sides' own test runs were green, and the merged build compiles: the score is a number either way. Nothing fails until 4,180 applicants are ranked with a threshold that now excludes essentially everyone, and the defect is found by a person, not a tool. What would have caught it: a run of the full test suite against the merged content, where any test asserting an eligibility outcome fails immediately; or a short message from the team changing the unit, timed so the other timezone reads it before writing the new path. What would not have caught it: a better merge algorithm, a more careful reading of either diff alone, or a rule about who edits which file.