After two months of intense work, the development community of Git introduces Git version 2.51, an update that It brings together 506 changes, in which 91 developers participated, of which 21 contributed for the first time.
This release introduces improvements designed to improve performance and simplify repository management, including performance optimizations for git-push and git-fetch, as well as several changes moving toward the new 3.x branch.
Git 2.51 Key New Features
One of the highlights of Git 2.51 is the Optimizing git push and git fetch commands in repositories with a large number of references. The key to this improvement is in the batch update, which processes multiple links in a single transaction rather than individually.
Thanks to this optimization, The reftable backend now outperforms the traditional files backend.In tests with repositories containing up to 10 references, git fetch performance increased by 000x for reftable and 22x for files, while git push improved by 1.25x and 18x, respectively.
Another important innovation is the iIntroduction of so-called cruft packages, designed to store inaccessible objects that are not linked to branches or tags. These objects, which were previously scattered, can now be managed in separate packagings, which makes them easier to control and reduces the size of multi-package indexes (MIDX).
With the new repack.MIDXMustContainCruft setting, Git avoids including these objects in the main indexesIn tests on GitHub, this configuration reduced index size by 38%, accelerated writes by 35%, and improved reads by 5%.
New approach to object packaging
El git pack-objects command incorporates the –path-walk option, which introduces an innovative method to reorganize packaging files. Instead of processing objects based on their hashes, Git can now iterate through them based on their file path, packing those that share the same location together. This approach eliminates the need to pre-sort objects and results in smaller, more efficient packing files.
With this version too A new format for exchanging working tree states and indexes created with Git Stash has been standardized.. It's now possible to export and import stashes just like branches or tags, making it easier to move states from one system to another.
For example:
git stash export --to-ref refs/stashes/mi-stash git push origin refs/stashes/mi-stash git fetch origin '+refs/stashes/*:refs/stashes/*' git stash import refs/stashes/mi-stash
Improvements to classic commands
Others Git commands have received relevant updates:
- git cat-file now reports missing objects and submodules, showing identifiers instead of just marking “missing”.
- git log benefits from Bloom filter optimizations, speeding up searches with multiple file paths.
- The git switch and git restore commands, considered experimental since 2019, are finally stabilized as modern alternatives to git checkout.
- The git whatchanged command, equivalent to git log –raw, is deprecated and will be removed in Git 3.0.
- git for-each-ref receives the –start-after option, which together with –count allows pagination of the output.
- git merge and git pull now include the –compact-summary option, which provides a more concise summary format.
C99 support and new contribution rules
Git continues to adapt its code to the characteristics of the C9 standard9. Although a compatible compiler is required since 2021, developers are moving cautiously to maintain compatibility with compilers that only partially implement it.
In addition, a significant change has been introduced in the contribution policy: Patches can now be submitted under a pseudonym, a decision aligned with the rules of the Linux kernel and designed to offer greater flexibility to contributors.
Looking ahead to Git 3.0
El The development team has also updated the roadmap to Git 3.0., where two key changes stand out: the default use of SHA-256 as the object identifier and the adoption of the reftable format for storing branch and tag references. These improvements aim to improve security and efficiency in increasingly large and complex repositories.
Source: https://lore.kernel.org