Git 2.48 now supports the Meson build system, a modern alternative to the existing Makefile, Autoconf, and CMake-based systems. This change addresses limitations in IDE support and maintenance issues with older systems.
According to Christian Couder, GitLab’s Git Expert, Meson offers several key advantages over previous build systems in Git 2.48. These include a user-friendly syntax, broad compatibility, support for modern features, and easy access to build options. The Meson build process involves setting up a build directory, compiling, testing, and installing using straightforward commands.
Git 2.48 has achieved a major milestone: it is now free of memory leaks, as exercised by its test suite. Previously, 223 test files had memory leaks, which were reduced to 60 by Git 2.47 and are now resolved. This accomplishment is aligned with the goal of “libifying” Git’s internal components (turning them into libraries) and optimizing memory usage. Unless exceptional justification is provided, new tests must now be leak-free by default.
Similar to regular fetches, fetches using bundle URIs can now undergo comprehensive validation using the fsck mechanism. This enhancement provides granular control over what issues are accepted or rejected based on severity levels. Previously unavailable for bundle fetches, this feature improves repository safety and usability.
In Git 2.48, work on reference consistency checks has progressed further. The git-fsck command can now detect issues such as invalid reference content or symbolic references pointing to non-existent targets. These checks were integrated into git-fsck after being developed as part of the Google Summer of Code (GSoC) 2024.
The tech communities on Lobster and Reddit engaged in discussions and shared their opinions on the announcement. This conversation thread on Lobsters noted that Git and GitHub still rely on SHA-1, despite known vulnerabilities. While Git includes safety measures, concerns exist about interoperability issues and the potential for accidental triggering of collision detection mechanisms.
Furthermore, Reftables, introduced in Git 2.45 as a backend for storing references (e.g., branches and tags), have seen performance improvements through iterator reuse. Previously, reading references required creating new iterators for each operation, which was inefficient for repeated reads. Now, a single iterator can be reused across multiple reads, resulting in a 7% speedup in creating references during transactions with random reads and the potential for further optimizations by reusing more states within iterators.
Git 2.48 has also added support for migrating reflogs between backends using the git refs migrate command. Previously, reflogs could not be converted between file-based and reftables backends during migration efforts introduced in Git 2.46. While this tool still cannot handle repositories with multiple worktrees, it removes a critical limitation for users adopting reftables in their repositories.
The ref-filter subsystem, used by commands like git branch, git tag, and git for-each-ref, has been optimized to improve performance when processing large numbers of references in repositories.
The original announcement blog highlights a number of contributors for their efforts and a complete list of contributors can be found in the project release notes.
