{"id":106023,"date":"2022-12-13T15:36:42","date_gmt":"2022-12-13T13:36:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-39"},"modified":"2022-12-13T15:36:42","modified_gmt":"2022-12-13T13:36:42","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-39","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-39","title":{"rendered":"Release of Git source code management system 2.39.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
After two months of development, the release of the distributed version control system Git 2.39 has been published. Git is one of the most popular, reliable, and high-performance version control systems, providing flexible means for nonlinear development based on branching and merging. To ensure the integrity of history and resilience to 'backdating' changes, implicit hashing of the entire previous history is used in each commit, and it is also possible to verify individual tags and commits with digital signatures from developers. <\/p>\n
Compared to the previous release, the new version includes 483 changes prepared with the participation of 86 developers, of whom 31 participated for the first time. Key innovations: <\/p>\n
\n
The 'git shortlog' team, designed to display summaries with statistics from the change history, has added the option '--group' for arbitrary grouping of commits by fields not limited to the author or committer. For example, to show a list of developers with information about the number of changes, including assistants mentioned in the 'Co-authored-by' field, you can use the command: git shortlog -ns --group=author --group=trailer:co-authored-by\n
The output of shortlog can be aggregated using formatting specifiers, and the '--group' option allows for significantly simplifying the creation of complex reports and eliminates the need for additional sorting commands. For example, to create a report showing how many commits for a given release were accepted in each month, you can specify: git shortlog v2.38.0.. --date='format:%Y-%m' --group='' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12. Previously, to perform a similar operation, it would have required the use of sort and uniq utilities: git log v2.38.0.. --date='format:%Y-%m' --format='' | sort | uniq -c. <\/p>\n
The capabilities of the «cruft packs» mechanism have been expanded, designed for the packaging of unreachable objects that have no references in the repository (neither branches nor tags point to them). Unreachable objects are deleted by the garbage collector, but they remain in the repository for a certain time before deletion to avoid race conditions. The «cruft packs» mechanism allows all unreachable objects to be stored in a single pack file, with the modification time of each object recorded in a separate table stored in a different file with the «.mtimes» extension, ensuring they do not overlap with the general modification time.\n
The duration of unreachable objects in the repository before actual deletion is defined by the «—prune=<date>» option. While the delay before deletion is a quite effective and practical way to prevent repository damage due to race conditions, it is not 100% reliable. To simplify the recovery of a damaged repository, the new release offers the ability to save missing objects, for which the «git repack» command has been enhanced with the «—expire-to» option, allowing a file to be specified for creating an external copy of all deleted objects. For instance, to save unreachable objects in the backup.git file that haven't changed in the last 5 minutes, you can use the command: git repack —cruft —cruft-expiration=5.minutes.ago -d —expire-to=..\\\/backup.git. <\/p>\n
The speed of the «git grep —cached» operation has significantly increased (up to 70%) when searching in areas where sparse checkout is applied and for which partial indices (sparse index) are available. Previously, when the «—cached» option was specified, the search was first conducted in the regular index and then in the partial ones, leading to noticeable delays when searching in large repositories.\n