Short answer: Merge made by the 'ort' strategy. is not an error. Git printed it because your git pull or git merge created a merge commit, and ort is the engine it used to build that commit. Ort has been Git’s default merge strategy since Git 2.34. Nothing needs fixing.
Introduction
Git keeps improving how it merges. The biggest change in years was ort, a new merge strategy written by Elijah Newren. It shipped in Git 2.33 in August 2021 and became the default in Git 2.34 in November 2021. If you have updated Git since then, every merge you make already uses it. In this post, I explain what ort is, why Git prints this message, and the one real decision behind it.
What is ORT?
ORT stands for “Ostensibly Recursive’s Twin”. It is a from-scratch rewrite of the old recursive strategy, which was the default before it. It produces the same kind of result, a three-way merge of your branch, the other branch and their common ancestor. The difference is the engine: ort was built to be much faster, to handle renamed files better, and to work out the whole merge before it touches your working tree.
Why Git prints this message
When git pull finds that both your local branch and the remote have new commits, it cannot simply fast-forward. It has to create a merge commit. Git then tells you which strategy made it. Before Git 2.34 the same event printed Merge made by the 'recursive' strategy. Now it prints ort. Same event, newer engine.
$ git pull origin main
Merge made by the 'ort' strategy.
src/app.php | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)Benefits of ORT
- Speed. Ort is much faster than recursive on large repositories, and the gap is widest when files were renamed.
- Less wasted work. It computes the merge in memory and only then updates your files, instead of rewriting the working tree as it goes.
- Better rename handling. It detects renamed files and directories more reliably, which means fewer confusing conflicts.
Considerations for Developers
- Compatibility. There is nothing to configure. The only thing that can break is a script that searches Git’s output for the word “recursive”.
- Learning curve. None. Conflicts look the same and you resolve them with the same commands.
- Migration. None. A repository does not store a merge strategy, so there is nothing to convert.
How to stop getting merge commits on every pull
If the message bothers you, the strategy is not the problem. The real question is whether git pull should create merge commits at all. Use git pull --rebase or git pull --ff-only, or set a default once with git config pull.rebase true. I explain all three options, and when each one fits, in what to do when Git says you have divergent branches.
For a team, I recommend deciding this once, as a written rule, instead of leaving it to each developer’s pull habits. Mixed habits are what turn a shared history into something nobody can read.
Conclusion
If you see Merge made by the 'ort' strategy., your merge worked. Ort is simply the engine Git now uses for it, and it is faster and safer than the one it replaced. The only decision worth your time is whether you want merge commits from pull in the first place.
FAQ
What does “Merge made by the ‘ort’ strategy” mean?
It means Git created a merge commit and used ort, its default merge strategy since Git 2.34. It is an information message, not an error.
Is the ort merge strategy safe to use?
Yes. It has been the default for every merge since Git 2.34. It produces the same kind of three-way merge as the old recursive strategy, faster and with better rename handling.
How do I stop git pull from creating merge commits?
Use git pull --rebase or git pull --ff-only, or set a default with git config pull.rebase true or git config pull.ff only.