In Git, what is the difference between a merge strategy (-s) and a strategy option (-X)?
answer
- One picks the algorithm
- The other configures that algorithm
- Same word, two very different flags
- Think ours as strategy versus option
basics
~20 s-s selects the algorithm that combines the branches, such as ort, ours, octopus or subtree. -X passes an option to that algorithm, such as ours, theirs, ignore-space-change or diff-algorithm, tuning how it resolves particular details.
solid answer
~40 s`-s` (`--strategy`) chooses *which* merge algorithm runs. `git merge -s ort` is the modern default for a two-branch merge; `-s ours` ignores the other side's content entirely; `-s octopus` is used automatically when you merge more than two heads; `-s subtree` shifts trees so a project merged into a subdirectory lines up. `-X` (`--strategy-option`) passes a parameter *into* the selected strategy, so the valid values depend on the strategy. For ort the common ones are `-X ours` and `-X theirs` (auto-resolve conflicting hunks toward one side), `-X ignore-space-change`, `-X diff-algorithm=histogram`, and `-X find-renames=<n>`. The confusing pair is `-X ours` versus `-s ours`: the option resolves only conflicting hunks in our favour and still takes the rest of their changes, while the strategy discards their content completely.
code
bash · 3 linesgit merge -s ort -X ignore-space-change feature
git merge -s ours obsolete-branch
git merge -X diff-algorithm=histogram featurego deeper
Recall the shape of the two flags: -s names the merge algorithm, -X passes it an option, and they are not interchangeable.
Explain the layering and give the discriminating example of -s ours versus -X ours, plus a couple of real options such as ignore-space-change.
Show judgment about auto-resolving options: they hide a real disagreement, so name where they are safe and how you would review the result.
Be ready to decide whether any of these belong in shared tooling or automation, and to say what evidence would justify standardising one.
## 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.
- Which strategy does Git use when you merge more than two branches at once?`octopus` is selected automatically for more than two heads, producing one commit with several parents. It deliberately refuses any merge that would need manual conflict resolution, so it is only useful for combining independent branches. `-s ours` also accepts any number of heads, but discards their content.
- Do -X options work with every merge strategy?No. Options are interpreted by the strategy that receives them, so the valid set depends on `-s`. The whitespace, rename and diff-algorithm options belong to the default three-way strategy; passing an unknown option makes the merge fail rather than being ignored.
- Can you pass strategy options to commands other than git merge?Yes. The merge machinery is shared, so `git rebase` and `git cherry-pick` accept `--strategy` and `--strategy-option` as well. Be careful with `ours` and `theirs` there: during a replay the sides are inverted relative to a plain merge, so the same option can produce the opposite outcome to the one intended.
saying these in an interview costs you the question
- Thinks -X ours and -s ours mean the same thing
- Believes any -X option works with any strategy
- Assumes a -s theirs strategy exists
- Says -X theirs discards our branch's commits
- Cannot name the default two-branch merge strategy