What makes a version-control merge report a conflict instead of merging automatically?
answer
- Two lines of work, one file region
- Each side is compared to a shared start
- Edits in different regions combine silently
- Same region changed differently on both sides
- No rule ranks two deliberate edits
basics
~20 sA merge reports a conflict when both lines of history changed the same region of a file since their common ancestor. Changes in different regions combine automatically; two different changes to one region leave the algorithm no basis to choose.
solid answer
~40 sA merge compares each of the two lines of history against the point they last shared, region by region. If only one side changed a region, that side's text is taken; if both sides changed it identically, the text is taken once; if neither changed it, the ancestor's text stays. A conflict is the one remaining case: **both sides changed the same region differently**. There is no rule that ranks two deliberate edits — later is not more correct, bigger is not more important — so instead of silently discarding someone's work the merge stops and asks a person. The same applies to file-level clashes, such as one side editing a file the other side deleted, or two sides adding different files at the same path.
go deeper
Be ready to say, in one sentence, that a conflict means both sides changed the same region since their shared starting point. Interviewers mostly want to hear that same-file is not the same as same-region, and that the tool stops rather than guessing.
Expect to walk through the case table: unchanged, changed on one side, changed identically, changed differently. Be able to name the non-overlap conflicts too — edit versus delete, rename versus edit, two files added at one path, and content with no lines to compare.
Show the judgement in the resolution rather than the mechanics. An interviewer wants to hear that you read the ancestor version, that the right answer is often text from neither side, and that you build and exercise the merged result before sharing it.
Own the framing that conflict frequency is a property of how the team works, not of the tool. Be ready to say what you would change when resolutions are routinely rushed, and how you would make dropped-on-resolution work visible rather than trusting care.
## What a merge is actually being asked to do Merging two lines of history means producing one version of the content that carries the intent of both. The algorithm doing that work is textual, and it knows exactly three inputs: the **common ancestor** (the most recent point both lines share), **the side already in place**, and **the side being brought in**. It has no model of what the code means, no knowledge of which team is more senior, and no access to the discussion that produced either change. For each file, and inside each file for each region of lines, it asks two questions: did this region change between the ancestor and one side, and did it change between the ancestor and the other side? The pair of answers decides everything. ## The five cases | Changed on one side | Changed on the other side | Result | |---|---|---| | no | no | keep the ancestor's text | | yes | no | take the changed text | | no | yes | take the changed text | | yes | yes, identically | take that text once | | yes | yes, differently | **stop and report a conflict** | Only the last row is a conflict, and that single fact clears up most of the confusion around this question. Two engineers can work in the same file all week without a single conflict, provided their edits land in different regions. Two engineers can conflict over a one-character change, if it lands on the same line. ## Why the algorithm refuses to guess In the conflicting case there are two candidate texts for one region and no rule that ranks them: - **Timestamps do not help.** The change made later is not the change that is more correct. - **Size does not help.** The larger edit is not the more important one. - **Authorship does not help.** The system has no idea who owns the intent. Any automatic choice would discard work somebody deliberately wrote, and the discarded work would leave no trace in the merged content — the worst possible failure for a system whose whole job is not losing changes. So the merge stops, leaves the undecided region showing both candidate versions for a person to read, refuses to record a result, and waits. ## Conflicts that are not two edits to one line Overlapping line regions are the common case, not the only one. A merge also has to stop when: - **Edits land close together.** Comparison works on blocks of lines plus surrounding context, so two changes a line or two apart can overlap as blocks even though no single line was touched twice. - **One side edited a file the other side deleted.** Neither keeping it nor dropping it can be inferred. - **One side moved or renamed a file the other side edited.** Rename detection is a heuristic; when it fails, you get a deletion on one side and an unrelated addition on the other. - **Both sides added a different file at the same path.** - **The content has no lines to compare** — an image, an archive, a compiled artefact. With no regions there is nothing to combine selectively, so any change on both sides is a whole-file conflict. ## Resolution is a decision, not a lookup The correct resolution is frequently text that appeared on neither side, because two intents have to be *combined* rather than chosen between. Reaching for one whole side is the classic beginner move: it is fast, it produces a clean result, and it silently deletes half of what was meant. A workable sequence: 1. Read **all three** versions of the region, the ancestor included. Without the ancestor you cannot tell which side changed what. 2. State the combined intent in words before typing. If both changes are still wanted, the result has to express both. 3. Read the whole file afterwards, not just the region — a locally correct resolution can leave the surrounding code inconsistent. 4. Build the merged content and run the tests on it. Neither side's own test run says anything about the combination. 5. Record the resolution, and explain the choice where it was not obvious. A conflict is not evidence that somebody did something wrong, and it is not a defect in the version-control system. It is the system declining to invent an answer to a question only a person can answer, and it is cheap: a few minutes of reading. The expensive failure is the rushed resolution that quietly drops one side's work and merges perfectly clean.
- Two people edit different functions in the same file all week. Does that merge cleanly?Usually yes — the merge works on regions, not files, so edits in separate parts of a file combine without anyone being asked. It stops only if the two regions overlap, which can happen when the edits sit a line or two apart, because the comparison includes surrounding context lines around each changed block.
- One side deleted a file that the other side edited. Why is that a conflict when only one region changed?Because the clash is at the file level, not inside a region. Keeping the file discards the deletion; dropping it discards the edit. Nothing in the three versions says which intent should win, so the merge presents both facts and waits for a person to decide.
- Why does one conflicted file stop the whole merge rather than merging the rest?The merge is recorded as a single result. Files that combined cleanly are already prepared, but nothing is committed until every path has an answer, so the working copy sits in a half-finished state. This is deliberate: a partially recorded merge would leave history claiming a combination that was never completed.
Two people take offline copies of the same document. If one rewrites the introduction and the other rewrites the conclusion, both edits can be reapplied mechanically; if both rewrite the same paragraph, no clerk can merge them without asking what was meant.
saying these in an interview costs you the question
- Thinks a conflict means someone did something wrong
- Believes editing the same file at all causes a conflict
- Says the more recent change automatically wins
- Cannot say what the common ancestor is for
- Always resolves by taking one whole side
- Records the resolution without building or testing it