Git 2.33 released with new optional merge process likely to become the default: It's 'over 9,000' times faster
- Reference: 1629220030
- News link: https://www.theregister.co.uk/2021/08/17/git_233/
- Source link:
Git releases are relatively frequent. Git 2.31 was released in March and Git 2.32 in June. According to the [1]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," [2]according to its creator Elijah Newren.
[3]
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.
[4]
[5]
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 [6]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."
[7]GitHub picks Friday 13th to kill off password-based Git authentication
[8]JavaScript, GitHub, AWS crowned winners in massive survey of 32,000 developers
[9]What is GitOps? This is the technical introduction you've been looking for
[10]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 [11]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 [12]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, [13]considers the Git Rebase command harmful and dislikes the inability to edit check-in comments, among other things. "The mental model for Git is needlessly complex," he [14]said .
[15]
Git 2.33 is no simpler than before, but faster and more correct merging is an unequivocal improvement. ®
Get our [16]Tech Resources
[1] https://lore.kernel.org/git/xmqq1r6touqi.fsf@gitster.g/
[2] https://public-inbox.org/git/CABPp-BFRftNf8hoj8nTDiw+akci=w2qVAgamVDyRw1NUk-QCNA@mail.gmail.com/#r
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YRwxmziGhmPLFCf@37RzOAAAAIc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YRwxmziGhmPLFCf@37RzOAAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YRwxmziGhmPLFCf@37RzOAAAAIc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://github.blog/2021-08-16-highlights-from-git-2-33/
[7] https://www.theregister.com/2021/08/12/git_proxyshell_gigabyte/
[8] https://www.theregister.com/2021/07/16/jetbrains_developer_survey_2021/
[9] https://www.theregister.com/2021/07/13/gitops_explained/
[10] https://www.theregister.com/2021/05/07/gitlab_certification_snafu/
[11] https://lore.kernel.org/git/4a0f088f3669a95c7f75e885d06c0a3bdaf31f42.1628055482.git.gitgitgadget@gmail.com/
[12] https://github.com/git/git/commit/546adc4950185464c75158301c854b0f55dcf465#diff-59e709e3d28c3902832be71d1e3e4a3d6c4dd2d87b3bf7de250f12520ef85cf2
[13] https://www.theregister.com/2019/12/03/github_git_sqlite_creator/
[14] https://sqlite.org/whynotgit.html
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YRwxmziGhmPLFCf@37RzOAAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[16] https://whitepapers.theregister.com/
Speak not evil in these four walls!
Brrr, speak not evil in these four walls, for those creations of the Terrible Trivium, Visual Source Safe, Mercurial and Rational are still at large in the world, wasting time, leeching productivity and blighting lives.
["If you only do the easy and useless jobs, you'll never have to worry about the important ones which are so difficult. You simply won't have the time, for there is always something to do to keep you from what you should really be doing." ~The Terrible Trivium]
Merging in the cloud
"...merge-ort was over 9,000 times faster than merge-recursive..."
When merging on a cloud hosted git repository, does merge -s ort mean merging in the O[o]rt cloud?
This one's golden
Is this a real world example of the "write one to throw away" idea? That is, *now* they know enough to write it for correctness and speed, now that they have encountered all the tricky corner cases and observed the behaviour of competing algorithms.
Nice of them, though, to make sure the prior not-so-good versions were quite good enough for use. Unusual for the real world from my experience!
Git is not a file revision system
One of the major thinking errors people make when switching from CVS, SVN, Hg, etc. to Git is that they assume that it is a file-based revision control system. Instead Git is essentially a filesystem. Or, as put in the Git documentation:
"Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot."
(Source: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F)
In this regard it's probably easiest to think of Git akin to ZFS and other snapshot-based filesystems. Within that mindset it's a lot easier to grok why Git is so painful to use where a file-based VCS would make so much more sense.
Re: Git is not a file revision system
I don't find that a particularly helpful mental model. I change files, I commit changes to files, and sometimes I tag a point in time. If the internal system is "like" a filesystem snapshot, well and good but I'm not thinking about filesystem snapshots.
As for pain, just use the Emacs Magit interface and move on.
Re: Git is not a file revision system
> why Git is so painful
I don't see why people think it's painful. Git is how I figured an SCCS would work before I ran into any SCCS.
My pain with git is remembering what command with which option does what I need to do.
I don't care what they've done - although it sounds awesome - I just never want to be in a place where my updates are so complex that they can be made 9000 times faster ...
"The mental model for Git is needlessly complex,"
Absolutely, and for 99% of projects Git is massively overkill. However, in many ways rather than keeping up to scratch in all of them, it has been nice to just simplify and stick to Git for everything. I found it a bit of a struggle working with mainly SVN, some CVS and bits of Perforce chucked in for good measure.
A mono-culture is never good but... at least Git is pretty decent this time. Imagine if the mono-culture was Microsoft TFS! :/