Configure Git to merge using ort
On Monday (2021–08–16), the Git project announced the 2.33 release. For me, its headline feature is a new merge strategy called ort.
If you have Git 2.33 installed, you can try the new strategy out in a repository by running:
git config pull.twohead ort(that’s correct and covers normal merges whether they happen during a git pull or otherwise).
Now, when you locally merge in changes from another branch, your copy of Git uses the “ort” strategy. It’s basically the same as the existing default strategy, “recursive”, but fixes a lot of the known bugs. And it’s much faster for big merges.
Once you’re happy it works, you can use it everywhere on your PC:
git config --global pull.twohead ortI’ve already switched and for me it’s working fine. I don’t usually make a special effort to keep tools up to date with the very latest upstream features, but:
- I do a lot of rebasing and merging with Git
- I wasn’t going to blog about an update I hadn’t already tried.
I didn’t have to co-ordinate with colleagues or customers for this. Git’s distributed model means you can switch to “ort” merges whilst the source control server and your colleagues are still on using “recursive”. Just imagine if you did need to all switch on the same day — that’d take a lot of planning.
You’ll start to see the “ort” merge mechanism making new Git features possible. For example, you can now easily detect when someone does a merge that’s different from how the automatic resolver would have done it. Someone unscrupulous might smuggle in some malicious changes during a manual merge and this will makes that kind of tampering much easier to spot.
Future enhancements
If you use Git’s rebase subcommand - I've no idea how people used to manage without - then you're probably used to needing to stash your changes first, or something similar. The way “ort” is implemented means you won't need to. That's going to be a huge improvement for local workflows.
The same improved algorithm, that doesn’t rely on a working tree, unlocks a chance for SaaS providers (GitHub, etc) to offer a better remote rebase experience too. I’m really looking forward to it.
Naming
Wondering about that name, “ort”? It’s a pun on the merge sort algorithm, coming from how you specify the strategy on the command line:
git merge -s ort <branch>or, shorter:
git merge -sort <branch>Gotta love a nerdy reference, right? If you really can’t get enough of those, check out the other names that were suggested.
I still think that Git is the worst version control system in the world, apart from all the other ones I’ve used.
At The Scale Factory, we believe in defining infrastructure as code, automated deployments, and effective code reviews. Whether you call it GitOps, DevOps, Site Reliability Engineering or just software development, we help teams build secure, highly available and cloud-native SaaS solutions.
Are you comfortable explaining what you know about git even if you can't cover every single detail? If so, and especially if you can also switch from talking technical to discussing deliverables, deadlines, and business value, then please check out our careers page.
We’re friendly and inclusive, so if you have the skills and experience, I hope you would consider applying regardless of your age, gender, sexuality, race or physical ability.
