What is Git's ort merge strategy, and how does it differ from the older recursive strategy?
answer
- Newer default two-branch strategy
- Three letters, an odd name
- Works on trees in memory
- Replaced recursive in Git 2.34
basics
~20 sort is a rewrite of the classic three-way merge strategy and the default for two-branch merges in modern Git. It works on tree objects in memory instead of through the index and working tree, making it faster and better at directory renames, with clearer conflict reporting.
solid answer
~40 s`ort` ("Ostensibly Recursive's Twin") replaced `recursive` as the default merge strategy in Git 2.34. Conceptually it does the same job: find the merge base, compare both sides against it, and combine. The difference is implementation. `recursive` drove the merge through the index and working tree, which meant intermediate merges — such as the virtual merge base built when several common ancestors exist — had to be materialised on disk. `ort` computes entirely in memory on tree objects, so it is markedly faster on large repositories and on histories with many merge bases, and it can merge without a working tree at all. It also handles directory renames more consistently and reports conflicts more precisely. `recursive` is still selectable with `-s recursive`, but for a normal two-branch merge there is little reason to.
code
console · 4 lines$ git merge feature
Merge made by the 'ort' strategy.
$ git merge -s recursive feature
Merge made by the 'recursive' strategy.go deeper
Just be able to name ort as the current default merge strategy and recursive as the older one it replaced.
Explain that both implement the same three-way merge, and that ort works on trees in memory instead of through the index, with better directory-rename handling.
Show version awareness: state the assumption of Git 2.34 or newer, and know that recursive stays selectable for reproducing historical merge results.
Frame it as an implementation upgrade with no semantic promise: plan client version expectations rather than assuming every developer's Git behaves identically.
## What ort is `ort` is Git's default merge strategy for combining two branches in modern Git — since 2.34. The name stands for "Ostensibly Recursive's Twin": it was written as a behaviour-compatible replacement for the long-standing `recursive` strategy rather than as a new merge model. Both implement the same three-way merge: locate the merge base (best common ancestor), diff each side against it, and apply both sets of changes, flagging regions both sides touched as conflicts. ## Why a rewrite was needed `recursive` was built on the index and working tree. Every merge step read and wrote real files, and the index was the scratch space where intermediate state lived. That has three consequences: - **Recursive merge bases are expensive.** When two branches have several equally good common ancestors (a criss-cross history), the strategy merges those ancestors together to build a single *virtual* merge base. Under `recursive`, each of those inner merges had to be materialised through the index and working tree. - **A working tree is required.** Operations that just want a merge result — server-side or scripted merges — still had to check files out. - **Cost scales with repository size, not change size.** Touching the index means paying for the whole tree even when the merge touches five files. `ort` computes on tree objects in memory, producing the resulting tree directly and only then updating the index and working tree if the caller wants them updated. That removes the per-step disk work, so the win is largest exactly where `recursive` hurt most: very large repositories and histories with many merge bases. ## Behavioural differences you can observe `ort` was written to produce the same result as `recursive` in the ordinary case, but it is not bug-compatible — several long-standing awkward cases were fixed: - **Directory rename handling** is more consistent. When one side renames a directory and the other adds files to the old location, `ort` places the new files into the renamed directory more reliably, and reports the case as a conflict when it is genuinely ambiguous. - **Conflict reporting is clearer**, with messages that identify the paths and the kind of conflict more precisely (rename/rename, rename/delete, modify/delete, and so on). - **Rename detection interacts better** with the rest of the merge, since it operates on trees rather than on an index snapshot. The merge output line tells you which strategy ran: `Merge made by the 'ort' strategy.` ## What did not change The strategy options you already know still apply: `-X ours`, `-X theirs`, `-X ignore-space-change`, `-X renormalize`, `-X diff-algorithm=<algo>`, `-X find-renames=<n>`, `-X no-renames`, `-X subtree=<path>`. Conflict markers, the meaning of a merge base, and the shape of the resulting merge commit are all unchanged. Switching strategies is not a way to get a different *kind* of history. ## When you would still name recursive `recursive` remains available as `-s recursive`, so if you need to reproduce a merge result exactly as an older Git produced it — for example while investigating why a historical merge came out the way it did — you can select it explicitly. Outside that kind of archaeology, there is no routine reason to opt out of the default. ## What interviewers are listening for This question is largely a currency check. A candidate who says "the default merge strategy is recursive" is repeating material that predates Git 2.34; naming `ort`, knowing it is the default, and being able to say *why* it exists — in-memory tree merging rather than index-and-working-tree merging, with better directory-rename behaviour — signals that you have read current documentation rather than an old tutorial. Be careful not to overclaim. Do not attach specific speedup numbers to it, and do not suggest it changes merge semantics in general; the honest framing is "same three-way merge, better implementation, some genuinely fixed edge cases". Also be precise about version: state that you are assuming Git 2.34 or newer, because on an older client the default really is `recursive` and the answer changes. ## Related mechanism worth mentioning Because `ort` can produce a merged tree without touching a working tree, it fits naturally into contexts where no checkout exists. That is the practical significance of "in memory" beyond raw speed: the merge result becomes a computation over objects rather than an operation on files.
- How can you tell which merge strategy a given merge used?The merge output states it, for example `Merge made by the 'ort' strategy.` You can also force a specific one with `-s recursive` or `-s ort` to compare results, which is occasionally useful when reproducing how an older Git resolved a historical merge.
- Does switching from recursive to ort change the merge result?In ordinary merges, no — ort was written to match recursive's behaviour. It does fix several edge cases, most visibly around directory renames, where the newer strategy places files more consistently and reports genuinely ambiguous situations as conflicts rather than guessing.
- Why does merging in memory rather than through the index matter?It removes per-step disk work, which dominates on large repositories and on histories with many common ancestors that require building virtual merge bases. It also means a merged tree can be computed without checking anything out, so a merge becomes a computation over objects rather than an operation on files.
saying these in an interview costs you the question
- Says recursive is still the default in modern Git
- Thinks ort is a rebase mode rather than a merge strategy
- Claims ort changes merge semantics in general
- Confuses ort with the ours strategy because of the name
- Attaches invented speedup figures to the rewrite