{"id":148781,"date":"2025-11-18T23:12:24","date_gmt":"2025-11-18T21:12:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52"},"modified":"2025-11-18T23:12:24","modified_gmt":"2025-11-18T21:12:24","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","title":{"rendered":"Release of the Git version control system 2.52","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
After three months of development, the release of the distributed version control system Git 2.52 has been announced. Git is known for its high performance and provides tools for nonlinear development based on branching and merging. To ensure the integrity of history and resilience against \"backwards\" changes, implicit hashing of all previous history in each commit is utilized, alongside 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 637 changes prepared by 94 developers (33 of whom contributed to Git for the first time). Key innovations (1, 2, 3): <\/p>\n
\n
The command \"git last-modified\" has been added to display a list of files in a specified revision and the commits that made the most recent changes to each of these files.\n\n$ git last-modified HEAD\nb56f6dcd7b4c90192018e848d0810f091d092913\ntest.h\n29330ae4b820147c98e723399e9438c8bee60a8a\ntest1.c\n573ad8917beb99dc643b6e7f5c117a294384a575\ntest2.c\n
The command \"git repo\" has been added to perform actions related to retrieving information from the repository. Two subcommands have been proposed: \"git repo info\" and \"git repo structure,\" which provide information about repository settings and details about the repository structure (e.g., the number of references and objects in the repository).\n\n$ git repo info object.format references.format\nobject.format=sha1\nreferences.format=reftable\n$ git repo structure\n| Repository structure | Value |\n| --------------------- | ----- |\n| * References | |\n| * Count | 1983 |\n| * Branches | 4 |\n| * Tags | 1125 |\n| * Remotes | 854 |\n| * Others | 0 |\n| * Reachable objects | |\n| * Count | 518955 |\n| * Commits | 77469 |\n| * Trees | 188865 |\n| * Blobs | 251631 |\n| * Tags | 990 |\n
Three subcommands have been added to the \"git refs\" command to unify disparate and overlapping low-level operations on references (git for-each-ref, git show-ref, git update-ref, and git pack-refs):\n
\n
\"git refs optimize\" \u2014 optimizes the backend storage of references (similar to \"git pack-refs\").\n
\"git refs list\" \u2014 outputs a list of all references (similar to \"git for-each-ref\" or \"git show-ref\").\n
\"git refs exists\" \u2014 checks for the existence of a reference (analogous to \"git show-ref --exists\"). <\/ul>\n
The format for exporting or importing commit history has been enhanced with the ability to work with cryptographic signatures that use object identifiers based on both the SHA-1 and SHA-256 algorithms. The command 'git fast-import' now supports processing signed tags similarly to signed commits. Options '--signed-commits=' and '--signed-tags=' have been added to manage the processing of signed commits and tags during import (the mode can be set to verbatim, warn-verbatim, warn-stri, strip, or abort).\n
The 'git maintenance' command has been updated to support a new 'geometric' strategy ('git config set maintenance.strategy geometric'), allowing for reduced maintenance time for large monorepositories. Compared to the previously available strategy, which used logic similar to the 'git gc' command, the new strategy avoids repacking all objects and eliminates overly resource-intensive operations, such as merging all pack files (where possible, merging is done in parts without cleaning up deleted objects).\n
A new command 'git sparse-checkout clean' has been added to simplify restoring the state of the working directory by removing files that do not match the new definition of sparse-checkout, which should not be present in the local copy according to the current sparse-checkout settings.\n
Refactoring has been carried out to simplify the codebase and reduce the use of the global variable the_repository.\n
The application of Bloom filters has been expanded, allowing for a probabilistic structure to check membership in a set, which permits false positives for missing elements while excluding misses for existing elements. Bloom filters are now used to expedite searches in the change history when specifying masks in file paths, for example, 'foo\/bar\/*\/baz'.\n
The performance of the 'git describe' command has been improved by up to 30% due to the use of a priority queue. The 'git remote rename' operations for renaming references have been accelerated. The use of indexes in 'git ls-files' has been expanded. The 'git log -L' command has seen a significant speedup by eliminating unnecessary three-level comparisons when processing merge commits. Optimizations have been made in the xdiff library.\n
An optional feature has been introduced that allows the use of Rust implementations for some internal functions, such as the encoding and decoding of variable-length integer values. By default, Rust code is not used, and to enable it, the build flag WITH_RUST must be specified. In the future, a redesign of more significant internal components of Git in Rust is expected, along with adding Rust to the mandatory build dependencies in Git 3.0.\n
The list of breaking changes that will be applied in Git version 3.0 has been updated. In Git 3.0, it has been decided to change the default setting for init.defaultBranch to \"main\"; that is, in repositories created with the \"git init\" command, the default branch will be named \"main\" rather than \"master\". It is also noted that there will be a default transition to object identifiers based on the SHA-256 hashing algorithm when initializing new repositories. To simplify compatibility between repositories with object identifiers based on SHA-1 and SHA-256 hashes, it will be possible to perform push and pull operations between repositories using different hashing algorithms. <\/ul>\n