Git 2.34 sets new merge default, speeds things up for monorepo users

git 2.34 monoliths

After three months of work, Git 2.34 is finally available for downloading. The update for the popular version control system continues to add enhancements meant to reduce waiting times, while also providing bits and pieces to make it a bit more comfortable to use.

Developers who already employ the automatic correction feature but find the immediate option a bit encroaching, for instance, can now try setting the help.autoCorrect configuration to prompt. Like this, Git will go into interactive mode when a subcommand is misspelled and ask if it should rerun the last operation with a suggested command.

Another helpful addition is a configuration called submodule.stickyRecursiveClone. It sets submodule.recurse configurations to true in repositories created using git clone --recurse-submodules, so that other commands recurse into them by default. For additional feedback, git bundle unbundle has been fitted with a progress display for the release, and there are some fixes included to ensure git pull’s rebase backend runs as intended in corner cases.

To improve security, Git 2.34 has learned to allow users to sign object and push-cert via ssh public crypto in addition to GnuPG, and now offers an adjusted credential-cache helper for Windows. Other than that the software is now able to use systemd timers as a possible backend for maintenance schedulers, report mismatches between expected and actual object types in git fsck, and highlight git log --grep=string --author=name hits properly.

The Git team changed the default merge strategy from recursive to ort (“ostensibly recursive’s twin”) with the update, something developers already discussed when the last feature release hit back in August. Back then, advocates mainly pointed out the alternative’s superior performance, extensibility, and correctness. 

The switch to the new merge backend is said to have helped expanding support for the sparse index format to commands merge, rebase, add, cherry-pick, and reset in Git 2.34. The concept of the sparse index lets Git create an index of the files within a sparse-checkout cone and was first introduced to the tool in v2.32. 

Concentrating on those files only naturally speeds up the indexing process, so it’s mainly of use to teams working with large monolithic repositories. Another addition to increase performance in those scenarios comes in the form of a new repacking strategy using multi-pack reachability bitmaps. 

Reachability bitmaps are used to compute the set of objects needed for a git fetch. Before the current iteration, these bitmaps could only cover objects in one packfile, which becomes somewhat inefficient when working with large monorepos. In contrast, the new multi-pack bitmaps are able to represent objects in multiple packs through utilisation of multi-pack index files that store object lists along with their offsets to improve lookup times.

A detailed list of internal changes and fixes added since v2.33 can be found in the Git repository.