What does setting Git's merge.conflictStyle to diff3 or zdiff3 add to conflict markers?

## The information the default style throws away A Git conflict is a three-way disagreement — base, ours, theirs — but the default conflict style, `merge`, prints only two of the three. You see your version and their version and are expected to reconstruct intent from that. Frequently you cannot. If your side reads `timeout = 30` and their side reads `timeout = 60`, you have no idea whether one of you changed it or both did; whether the base was `30` (they raised it) or `45` (you both lowered it, differently) changes the right answer completely. ## What diff3 adds Setting the config key `merge.conflictStyle` to `diff3` makes Git write a third section into every conflict hunk. The layout becomes: `<<<<<<<` and your side, then a `|||||||` line introducing the **merge-base** version of the same region, then `=======`, then their side, then `>>>>>>>`. With the base visible, resolving stops being a guess. You read the hunk as two diffs from a shared original and can usually combine both intents instead of picking a side. It also exposes the common case where one side did not really change the logic at all — a rename, a reflow, an import reorder — which the two-way view makes look like a substantive disagreement. The cost is size. Conflict hunks become roughly half again as long, and in a large conflicted region the base block can be big. ## What zdiff3 adds on top `zdiff3`, available from Git 2.35, produces the same three sections but runs a *zealous* pass first: lines at the start or end of the conflict region that are identical on **both** sides are hoisted out of the conflict entirely and left as ordinary merged text. Only the genuinely divergent core stays between the markers. In practice this often turns a twenty-line conflict — most of it identical boilerplate that happened to sit inside the conflicting region — into a three-line one. If your Git is recent enough, `zdiff3` is generally the better default than `diff3`; the extra context is preserved but the noise is not. ## Setting and changing it The key is ordinary Git config, so it obeys the usual scopes: `git config --global merge.conflictStyle zdiff3` for yourself, or a repository-local setting for a repo whose conflicts are habitually gnarly. It affects how future conflicts are *written* into the working tree. If you are already staring at a conflict written in the default style, you do not have to abort and retry: `git checkout --conflict=diff3 <file>` (or `--conflict=zdiff3` on a Git that supports it) rewrites that file's conflict hunks from the index stages in the chosen style. The same mechanism gives you `git checkout -m <file>`, which re-creates the conflict markers after you have mangled the file — useful when a botched manual edit has lost the original hunk. All of these work because the three versions are still sitting in the index at stages 1, 2 and 3; the working-tree text is only a rendering of them. ## How this interacts with tooling Merge tools that read the index directly — via `git mergetool` — usually show you base, ours and theirs in separate panes regardless of `merge.conflictStyle`, because they are pulling the stages, not parsing markers. The conflict style matters most for people who resolve conflicts in a plain editor, which is still the majority of resolutions. It also matters for automated checks: anything that greps for `<<<<<<<` should be aware that `|||||||` is an equally valid marker line to catch. ## Why interviewers ask It is a cheap probe for whether someone resolves conflicts deliberately or by reflex. A candidate who has never wondered what the original text was tends to resolve by picking whichever side looks familiar. A candidate who runs `diff3` or `zdiff3` is signalling that they treat a conflict as two intents to reconcile, and that they know a conflict is fundamentally three-way even though the default rendering is two-way.