{"id":141016,"date":"2025-08-19T11:11:54","date_gmt":"2025-08-19T09:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51"},"modified":"2025-08-19T11:11:54","modified_gmt":"2025-08-19T09:11:54","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","title":{"rendered":"Release of Git source control system 2.51","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
After two months of development, the release of the distributed version control system Git 2.51 has been announced. Git is distinguished by its high performance and provides tools for non-linear development based on branching and merging. To ensure the integrity of history and resilience to \"backward\" changes, implicit hashing of the entire previous history in each commit is used, as well as certification with digital signatures from developers for individual tags and commits. The Git code is distributed under the GPLv2+ license. <\/p>\n
Compared to the previous release, the new version includes 506 changes made with the participation of 91 developers (21 participated in Git development for the first time). Key innovations (1, 2, 3): <\/p>\n
\n
The performance of the commands \"git push\" and \"git fetch\" has been enhanced in repositories with a large number of references. The acceleration is achieved through batch updating of references, where several references are processed in one transaction instead of creating a separate transaction for each reference update. This optimization has significantly increased the speed of the \"reftable\" backend, which now outperforms the \"files\" backend. For example, in a test repository with 10,000 references, the performance of \"git fetch\" using the \"reftable\" backend increased 22 times, while with the \"files\" backend it increased by 1.25 times. For \"git push\", the gain was 18 and 1.21 times, respectively.\n
A new method for packaging parts of the repository in pack files, unrelated to tracking unreachable objects that are not referenced in the repository (branches or tags do not point to them), has been proposed. Information about unreachable objects is stored in separate pack files (\"cruft packs\"), which led to the necessity of reflecting them in multi-pack indices MIDX (multi-pack index) to cover objects that were originally unreachable and stored only in a cruft pack, but later became reachable after the referencing commit.\n
In the new version, the repacking of pack files ensures the preservation of additional copies of reachable objects stored only in cruft files. This change guarantees that the set of pack files used for storing reachable objects does not contain objects that reference other objects stored outside this set. To exclude unreachable content from multi-pack indexes (MIDX) of cruft files, the setting 'repack.MIDXMustContainCruft' has been proposed, allowing a significant reduction in the size of such indexes. Enabling this setting in the GitHub repository has reduced the size of MIDX indexes by 38%, accelerated write operations to MIDX indexes by 35%, and improved read performance by 5%. <\/p>\n
The command 'git pack-objects' has been enhanced with the option '--path-walk', which incorporates a new method for gathering information about objects when repacking pack files. Instead of traversing objects in revision order, when using the '--path-walk' mode, objects are iterated by traversing file paths, allowing all objects with the same file path to be packaged at once. This approach eliminates the heuristic that uses hashing to determine an object's link to its file path and also removes the need for sorting objects before packaging. In '--path-walk' mode, the size of the generated pack files is significantly smaller than when grouping objects using hashes.\n
A format has been defined for exchanging saved working directory and index states in a repository created using the 'git stash' command. The new format allows encoding saved changes (stash entries) as a sequence of commits. For import and export, the subcommands 'git stash import' and 'git stash export' have been proposed, which can be used to transfer saved states from one system to another and perform push or pull operations with these states as if they were regular branches or tags. git stash export --to-ref refs\/stashes\/my-stash git push origin refs\/stashes\/my-stash ... git fetch origin '+refs\/stashes\/*:refs\/stashes\/*' git stash import refs\/stashes\/my-stash\n
In the «git cat-file» command, which displays the contents of specified objects, the options «—batch» and «—batch-check» have been enhanced to show information about missing objects (for instance, due to repository corruption) and submodules. Previously, when indicating a path for a submodule, the command «git cat-file —batch-check» would output «missing», but it will now show the object identifier.\n
The «git log» command has implemented optimizations using Bloom filters to speed up the search in the change history when specifying filters with multiple file paths, such as «git log — path\/to\/a path\/to\/b».\n
The «git switch» and «git restore» commands, which have been considered experimental since 2019, have been stabilized. These commands present a modern equivalent to «git checkout», separating such loosely related functionalities as branch manipulation (switching and creating) and restoring files in the working directory.\n
The «git whatchanged» command, equivalent to «git log —raw», has been marked as deprecated and is planned for removal in the Git 3.0 branch.\n
The «git for-each-ref» command has introduced the «—start-after» option, which can be used in conjunction with the «—count» option for pagination.\n
The «git merge» and «git pull» commands have added the «—compact-summary» option to utilize a compact format for the summary of changes instead of the diffstat format.\n
The Git codebase has allowed the use of the «bool» keyword, which appeared in the C99 standard. Additionally, some C99 features that are experimentally used in Git are now documented (for example, allowing constructs like «(struct foo){ .member = value };» is planned for mid-2026). A C99-compliant compiler has been required for Git since 2021, but C99 specifications are being introduced very cautiously to maintain compatibility with compilers that only partially support this standard.\n
The patch acceptance rules have been amended to allow the submission of patches under a pseudonym, rather than only under the developer's real name. This change aligns with the patch acceptance rules in the Linux kernel.\n
The list of compatibility-breaking changes that will be implemented in the Git 3.0 branch has been updated. Notable changes in the upcoming Git 3.0 release include the default switch to object identifiers based on the SHA-256 hashing algorithm when initializing new repositories and the adoption of the \"reftable\" format for storing references to branches and tags in the repository (utilizing a block storage system from the JGit project, optimized for storing a very large number of references). <\/ul>\n