Git 2.33 puts new merge backend on the home stretch, improves things for avid scripters

Git 2.33 puts new merge backend on the home stretch, improves things for avid scripters

Git core maintainer Junio C Hamano has pushed the button and released version 2.33 of the version control system into the hands of software developers everywhere. And while most changes have taken place under the hood, there are still some bits and pieces to improve the general user experience and make life a little easier.

Git 2.33 for example allows users to specify a –no-commit-header when working with git rev-list. This will repress the typical commit + object ID lines when using the –pretty flag with a custom format, which should help in various scripting scenarios. Another helpful addition records why the worktree is locked when using git worktree add –lock, while a guideline for gender neutral documentation reaches out to anyone who is having trouble with inclusive language.  

Since the last release git send-email was slightly optimised and fitted with a  -sendmail-cmd command line option and a sendemail.sendmailCmd configuration variable which should provide a more sensible approach than repurposing the smtp-server. The Git team also worked on staple commands like checkout and commit, which have stopped to unnecessarily expand sparse indices.

Other “invisible” improvements include Git now using the hashfile API in the codepath that writes the index file to reduce code duplication, git log no longer wasting cycles on loading unnecessary ref decoration data, and the git status codepath finally working with sparsely populated indices.

According to Hamano, preparation work for a new merge strategy backend is now on its final stretch. Merge-ort is pitched as a complete re-write of the currently used recursive approach, that is meant to fix issues in areas like correctness, and performance. It is also said to provide the foundation for new features; amongst others a command to see what changes a user already made to resolve conflicts as well as an option to show the difference between an automatic merge and what was recorded. 

Users interested in taking the new backend for a spin before it becomes the default can do so by running git merge -s ort or set the pull.twohead configuration to ort.