In Git, what is the difference between a merge strategy (-s) and a strategy option (-X)?

## Two different levels of control Git's merge command takes two related but distinct knobs: - `-s <strategy>` / `--strategy=<strategy>` picks the **algorithm**. - `-X <option>` / `--strategy-option=<option>` passes a **parameter to that algorithm**. Because the option is interpreted by the strategy, the set of valid `-X` values depends on which `-s` you are running. Passing an option a strategy does not understand is an error, not a silent no-op. ## The strategies **`ort`** — the default for a normal two-branch merge in modern Git. It performs the three-way merge: compare both sides against their common ancestor and combine the changes, reporting conflicts where both sides changed the same region. **`recursive`** — the older implementation of the same idea, still selectable with `-s recursive`. **`resolve`** — an older, simpler two-head merge that does not build a virtual merge base when several common ancestors exist. **`ours`** — resolves any number of heads by producing a merge commit whose tree is exactly the current branch's tree. The other branches' content is discarded entirely; only the ancestry link is recorded. **`octopus`** — the default when you merge more than two heads at once. It handles many branches in one commit but refuses to proceed if the merge needs manual conflict resolution. **`subtree`** — a variant of the normal merge that shifts the trees so that a project living in a subdirectory of one side lines up with a repository merged from the other side. ## The options For the default strategy, the frequently used `-X` values are: - `-X ours` / `-X theirs` — when a hunk conflicts, take that side automatically instead of leaving conflict markers. Non-conflicting changes from **both** sides are still applied. - `-X ignore-space-change`, `-X ignore-all-space`, `-X ignore-space-at-eol`, `-X ignore-cr-at-eol` — treat whitespace differences as non-conflicting, useful when one side reindented a file. - `-X renormalize` — re-run the configured checkout/checkin conversions on the three stages before merging, which defuses line-ending churn. - `-X diff-algorithm=histogram` (also `patience`, `minimal`, `myers`) — change how the underlying diff is computed, which changes where hunk boundaries land and therefore what conflicts. - `-X find-renames=<n>` and `-X no-renames` — tune or disable rename detection. - `-X subtree=<path>` — the option form of the subtree shift, naming the path explicitly. Several `-X` options can be combined: `git merge -X ignore-space-change -X diff-algorithm=histogram feature`. ## The classic confusion `-s ours` and `-X ours` share a word and do very different things: - `git merge -s ours other` — the merge commit's tree equals the current branch's tree. Nothing from `other` is taken, not even changes to files nobody else touched. - `git merge -X ours other` — a normal three-way merge that takes every non-conflicting change from `other`, and only for hunks where both sides changed the same region picks our version silently. The mirror asymmetry is worth knowing too: `-X theirs` exists, but there is **no `-s theirs` strategy**. ## Where else these apply The merge machinery is shared, so `--strategy` and `--strategy-option` are also accepted by other commands that replay or combine commits, including `git rebase` and `git cherry-pick`. An option you set for a merge behaves the same way there, though "ours" and "theirs" refer to different sides during a replay than during a merge, which is a well-known source of mistakes. ## How to answer this in an interview State the layering in one sentence — strategy is the algorithm, option is a parameter to it — then immediately give the discriminating example, `-s ours` versus `-X ours`. That single contrast demonstrates you understand both levels rather than having memorised a flag list. If asked which strategy is the default, naming `ort` (with `recursive` as its predecessor) is the detail that separates a candidate who has read modern Git documentation from one repeating older material. ## A practical caution Strategy options that auto-resolve conflicts — `ours`, `theirs` — remove the conflict markers but not the disagreement. Git silently discards one side's edit to that region, and nothing in the resulting commit records that a choice was made. They are safe on genuinely derived content and dangerous on hand-written code, so a considered answer pairs the mechanics with a note about reviewing the resulting diff.