Git 2.33 released with new optional merge process likely to become the default: It's 'over 9,000' times faster

Git 2.33 has been released, including a new optional merge process called merge-ort, which the team hopes will become the default in the next version.

Git releases are relatively frequent. Git 2.31 was released in March and Git 2.32 in June. According to the release announcement, version 2.33 "does not have many end-user facing changes and new features" aside from fixes and internal improvements – but there is one major change, described as a "new merge strategy backend."

The strategy in question is merge-ort, where ort stands for "Ostensibly Recursive's Twin," according to its creator Elijah Newren.

A merge strategy is the mechanism used to combine code from multiple versions of the same codebase. Merging is a critical feature of distributed version control systems since it avoids the need for locking a main version when a checked-out copy is being edited. Merge mechanisms work by comparing the contents of a file with the contents of its ancestor, to identify changed sections, and then comparing the changed sections of one file with those of another.

There might not always be a single ancestor file, though, and in this case a recursive merge can be used to merge candidate ancestors and then treat the merged file as the ancestor. "This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history," say the docs. The merge-recursive is the Git default. Another, called octopus, is designed for merging files with more than two heads, and is the default when merging more than one branch.

GitHub senior software engineer Taylor Blau said that merge-recursive has had "several bugs over the years around tricky corner cases" and that in certain large cases it "could be very slow." Merge-ort, he said, "is a from-scratch rewrite" which used the same concepts but "solving many of the long-standing correctness and performance problems."

• GitHub picks Friday 13th to kill off password-based Git authentication
• JavaScript, GitHub, AWS crowned winners in massive survey of 32,000 developers
• What is GitOps? This is the technical introduction you've been looking for
• GitLab's 10-day certification freebie offer lasted only two because, surprise surprise, people really like freebies

In one example operation, merge-ort was over 9,000 times faster than merge-recursive, he said, while in another "very tricky" case it was over 500 times faster. He also said that merge-ort is better optimised to not access unchanged parts of a source code tree, and better suited for integrating with other tools. In this post, Newren summarises the benefits of merge-ort as being in the areas of correctness, extensibility, and performance. Merge-ort can be used in Git 2.33 with the command:

merge -s ort

There are some other smaller changes in 2.33, including improvements to the send-email command, a guideline for gender-neutral documentation, and other updates to the documentation "not to assume users are of certain gender."

Git, developed by Linus Torvalds for Linux code, now dominates version control systems, but it is not the easiest or most intuitive to use. Dr D Richard Hipp, creator of the Sqlite database manager as well as a competing version control manager called Fossil, considered the Git Rebase command harmful and disliked the inability to edit check-in comments, among other things. "The mental model for Git is needlessly complex," he wrote on a webpage titled, "Why SQLite Does Not Use Git."

Git 2.33 is no simpler than before, but faster and more correct merging is an unequivocal improvement. ®