⚡ TL;DR
Understand Git's ort and recursive merge strategies. What orthogonal history means, why ort replaced recursive as the default in Git 2.34, and how conflicts are resolved.
A Comparative Analysis of Git Merge Strategies: Ort vs. Recursive
In Git, merge strategies play a crucial role in harmonizing changes from different branches. Two significant strategies, “ort” (Ostensibly Recursive Three-way) and the traditional recursive, offer unique merging approaches, each with its strengths and applications.
If you’ve ever seen “Merge made by the ‘ort’ strategy” after running git merge, here’s the short version: ort is the rewrite of the old recursive strategy and has been Git’s default merge strategy since Git 2.34. It produces the same basic three-way merge but is faster on large repositories and handles renames (including directory renames) noticeably better. You rarely need to specify a strategy by hand — Git picks ort automatically, and git merge -s recursive now just falls back to ort anyway.
What “Orthogonal History” Actually Means
The title’s “orthogonal” refers to the situation a merge is built for. Two branch histories are orthogonal when they share a common ancestor but have evolved independently — neither branch contains the other, and their changes don’t coordinate with each other. Picture two straight lines crossing at a single point (the merge base): each branch touched its own set of commits, and now you want a merge commit that joins them without rewriting either history.
That’s exactly the case git merge branchname handles: Git finds the best common ancestor (the merge base) between your current branch and the target branch, then performs a three-way merge of the base snapshot, your branch’s snapshot, and the target’s snapshot. When both sides changed the same lines of the same file, the histories collide at that point and Git declares a conflict for you to resolve. When the changes touched different files or different regions, the merge completes automatically. (The rarer case where a branch has multiple independent merge bases — criss-cross merges — is where recursive/ort’s name comes in: both strategies recursively merge the multiple bases into a single virtual ancestor before the real three-way merge.)
Performance
Recursive Strategy
For many years, recursive was Git’s default merge strategy and is generally effective for various merge scenarios. However, it may face efficiency issues in large repositories or complex merge histories, particularly around rename detection.
Ort Strategy
“Ort” (“Ostensibly Recursive’s Twin”) is a rewrite of the recursive strategy introduced to tackle its performance challenges. It uses a clearer internal architecture and cached-tree information to dramatically speed up merge operations — benefits that show up most in large repositories. As of Git 2.34 (October 2021), ort is the default merge strategy, so git merge uses it without any configuration. Its rename detection is also improved: ort better follows files that were renamed, handles directory rename detection more correctly, and propagates conflicts involving renamed files more accurately than recursive did.
Conflict Resolution
Recursive Strategy
The recursive strategy provides basic conflict resolution capabilities: it auto-merges non-overlapping changes and flags genuinely conflicting hunks for manual resolution. It does not — despite what you may have read — “automate” conflict resolution; anything it can’t combine cleanly is left to you.
Ort Strategy
Ort has the same goal but performs better on the tricky cases: it produces fewer spurious conflicts involving renames, marks rename/rename and rename/delete situations more precisely, and generally leaves cleaner conflict markers. You still resolve real conflicts by hand — ort just presents fewer, more accurate ones.
Flexibility
Recursive Strategy
As the long-standing default, the recursive strategy has widespread support and understanding within the Git ecosystem.
Ort Strategy
Designed as a cleaner rewrite, ort is easier for Git developers to extend, and it underpins other modern behaviors (such as parts of git rebase and git stash merges). For day-to-day users, though, the interface is identical — no new flags to learn.
Default Behavior
Recursive Strategy
Before Git 2.34, git merge defaulted to the recursive strategy unless another strategy was explicitly specified.
Ort Strategy
Since Git 2.34, ort is what Git uses for ordinary merges by default. You shouldn’t need to switch strategies manually; -s ort and -s recursive now resolve to the same code path. Other strategies still exist for special cases — resolve (a simpler three-way merge), octopus (merging more than two heads), and subtree (merging across different tree roots).
In summary, you almost never have to choose: modern Git selects ort for regular merges automatically. The practical takeaway is to know what the message means, understand that ort is the faster, rename-aware successor to recursive, and recognize that both strategies only ask for your help when orthogonal changes genuinely collide.
Related Posts
- Essential Git Skills: How to Delete Remote Branches
- Solving Git Checkout Problems: Windows Users Encounter ‘Filename Too Long’ Error
FAQ
What does “Merge made by the ort strategy” mean in Git?
It means Git completed your merge using the ort strategy, the default since Git 2.34. Ort (“Ostensibly Recursive’s Twin”) is a rewrite of the older recursive strategy that performs the same three-way merge but runs faster on large repositories and handles file and directory renames more accurately. No action is needed — the message simply reports success.
What is orthogonal history in Git merging?
Orthogonal history describes two branches that share a common ancestor but evolved independently, with changes that don’t coordinate with each other. When you merge them, Git finds the best common ancestor as the merge base and performs a three-way merge. If both branches touched the same lines, the histories collide and Git raises a conflict for you to resolve.
Why did Git replace recursive with the ort merge strategy?
Recursive struggled with performance in large repositories, especially around rename detection. Ort is a cleaner rewrite that uses cached-tree information to speed up merges, detects directory renames more correctly, and produces fewer spurious conflicts. Since Git 2.34 (October 2021), ort is the automatic default, and -s recursive now falls back to the same code path.
Do I need to choose a merge strategy manually in Git?
Almost never. Modern Git selects ort automatically for ordinary merges, and other strategies cover special cases only: octopus merges more than two heads, resolve does a simpler three-way merge, and subtree merges across different tree roots. You specify a strategy by hand only when facing an unusual merge that the default handles poorly.
Written by Mihir Pipermitwala
Senior Full Stack Consultant & Mobile Engineering Specialist building user-focused applications in healthcare with Flutter, Dart and React Native. I write about what I actually build and test — every tutorial here comes from real project work.
More about Mihir →
