Home » Blog » Configure Git to merge using ort

Configure Git to merge using ort

Try out the newest merge strategy for Git.
Casestudy Graphic Hero

Industry

Outcomes

  • Scale Securely

Services

  • Cloud Engineering

Organisation Size

Published

Author

Share:

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 ort

I’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.


Consultation Bottombar Graphic
Not sure where to start

01 | Industry challenges discussion

02 | Compliance requirements review

03 | Solution approach outline

04 | Next steps & roadmap

Thinking about
a similar

challenge?

We work with organisations across regulated and complex industries to build the foundations for AI-enabled growth.

Related Insights

What would you like to search for?