The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск системы управления исходными текстами Git 2.52

18.11.2025 17:28

После трёх месяцев разработки представлен релиз распределенной системы управления исходными текстами Git 2.52. Git отличается высокой производительностью и предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Код Git распространяется под лицензией GPLv2+.

По сравнению с прошлым выпуском в новую версию принято 637 изменений, подготовленных при участии 94 разработчиков (33 впервые приняли участие в разработке Git). Основные новшества (1, 2, 3):

  • Добавлена команда "git last-modified" для отображения списка файлов в указанной ревизии и коммитов, через которые вносились последние изменения в каждый из этих файлов.
    
       $ git last-modified HEAD
    
       b56f6dcd7b4c90192018e848d0810f091d092913        test.h
       29330ae4b820147c98e723399e9438c8bee60a8a        test1.c
       573ad8917beb99dc643b6e7f5c117a294384a575        test2.c
    
  • Добавлена команда "git repo" для выполнения действий, связанных с извлечением информации из репозитория. Предложены две подкоманды - "git repo info" и "git repo structure", выводящие информацию о настройках репозитория и сведения о структуре репозитория (например, можно узнать число ссылок и объектов в репозитории).
    
       $ git repo info object.format references.format
    
       object.format=sha1
       references.format=reftable
    
       $ git repo structure
      
       | Repository structure | Value  |
       | -------------------- | ------ |
       | * References         |        |
       |   * Count            |   1983 |
       |     * Branches       |      4 |
       |     * Tags           |   1125 |
       |     * Remotes        |    854 |
       |     * Others         |      0 |
       |                      |        |
       | * Reachable objects  |        |
       |   * Count            | 518955 |
       |     * Commits        |  77469 |
       |     * Trees          | 188865 |
       |     * Blobs          | 251631 |
       |     * Tags           |    990 |
    
  • В команду "git refs" добавлены три подкоманды, унифицирующие разрозненные и пересекающиеся низкоуровневые операции над ссылками (git for-each-ref, git show-ref, git update-ref и git pack-refs):
    • "git refs optimize" - оптимизация бэкенда хранения ссылок (по аналогии с "git pack-refs").
    • "git refs list" - вывод списка всех ссылок (по аналогии с "git for-each-ref" или "git show-ref").
    • "git refs exists" - проверка существования ссылки (аналог "git show-ref --exists").
  • Формат для экспорта или импорта истории коммитов расширен возможностью работы с криптографическими подписями, использующими как идентификаторы объектов на базе алгоритма SHA-1, так и на основе SHA-256. В команде "git fast-import" реализована поддержка обработки подписанных тегов по аналогии с подписанными коммитами. Добавлены опции "--signed-commits=<режим>" и "--signed-tags=<режим>" для управления обработкой подписанных коммитов и тегов на этапе импорта (режим может принимать значения verbatim, warn-verbatim, warn-stri, strip или abort).
  • В команду "git maintenance" добавлена поддержка новой стратегии "geometric" ("git config set maintenance.strategy geometric"), позволяющей сократить время обслуживания крупных монорепозиториев. По сравнению с ранее доступной стратегией, использующей логику как в команде "git gc", новая стратегия избегает переупаковки всех объектов и исключает излишне ресурсоёмкие операции, такие как слияние всех pack-файлов (по возможности объединение производится частями и без чистки удалённых объектов).
  • Добавлена команда "git sparse-checkout clean" для упрощения восстановления состояния рабочего каталога, путём удаления файлов, не соответствующих новому определению sparse-checkout, которые не должны присутствовать в локальной копии в соответствии с текущими параметрами sparse-checkout.
  • Для избавления кодовой базы от усложнений и упрощения сопровождения проведён рефакторинг для уменьшения использования глобальной переменной the_repository.
  • Расширено применение фильтров Блума, вероятностной структуры для проверки вхождения во множество, допускающей ложное определение отсутствующего элемента, но исключающая пропуск существующего элемента. Фильтры Блума теперь применяются для ускорения поиска в истории изменений при указании маскок в файловых путях, например, "foo/bar/*/baz".
  • Производительность команды "git describe" повышена до 30%, благодаря использовании очереди приоритетов. В "git remote rename" ускорены операции переименования ссылок. В "git ls-files" расширено применение индексов. Заметно ускорена работа команды "git log -L", благодаря исключению излишних трёхуровневых сравнений при обработке слияния коммитов. Внесены оптимизации в библиотеку xdiff.
  • Предоставлена опциональная возможность использования реализаций на языке Rust некоторых внутренних функций, таких как кодирование и декодирование целочисленных значений переменной длины. По умолчанию код на Rust не используется и для включения требует указания сборочного флага WITH_RUST. В будущем ожидается переработка на Rust более значительны внутренних компонентов Git и добавление Rust в число обязательных сборочных зависимостей в Git 3.0.
  • Обновлён список нарушающих совместимость изменений, которые будут применены в ветке Git 3.0. В Git 3.0 решено изменить настройку init.defaultBranch по умолчанию в значение "main", т.е. в репозиториях, созданных командой "git init", ветка по умолчанию будет именоваться "main", а не "master". Также отмечается переход по умолчанию на идентификаторы объектов на основе алгоритма хэширования SHA-256 при инициализации новых репозиториев. Для упрощения переносимости между репозиториями с идентификаторами объектов на базе хэшей SHA-1 и SHA-256 предоставлена возможность в репозитории с одним алгоритмом хеширования, выполнять операции push и pull из репозитория, использующего другой алгоритм хеширования.


  1. Главная ссылка к новости (https://lore.kernel.org/lkml/x...)
  2. OpenNews: В Git 3.0 предложено сделать Rust обязательной частью сборочной инфраструктуры
  3. OpenNews: Выпуск системы управления исходными текстами Git 2.51
  4. OpenNews: Уязвимости в Git, допускающие выполнение кода при обращении к внешнему репозиторию
  5. OpenNews: Доступна децентрализованная система отслеживания ошибок git-bug 0.9
  6. OpenNews: Выпуск системы управления исходными текстами Git 2.50
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64279-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (17) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Аноним (3), 18:35, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все говорят что раст это плохо. Но ведь runtime зависимости не будет. Problems, officer?
     
  • 1.4, Анонисссм (?), 18:38, 18/11/2025 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –2 +/
     

  • 1.6, Аноним (6), 18:43, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > В будущем ожидается переработка на Rust более значительны внутренних компонентов Git и добавление Rust в число обязательных сборочных зависимостей в Git 3.0.

    Всё, фризимся на 2.52

     
     
  • 2.14, Аноним (14), 20:06, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зачем? Если раст будет полноценно поддерживаться в gcc без всякого копролита вроде llvm, то какая разница?
     
     
  • 3.15, Аноним (6), 20:20, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хм... так-то да.
     

  • 1.7, xsignal (ok), 18:47, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Гит только для ядра годится, потому что писался для этого и Торвальдсом под себя. Для обычных проектов есть куда более удобные системы хранения версий.
     
     
  • 2.8, Аноним (6), 18:53, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Гит только для ядра годится

    А только для линуксового ядра? Или для других ядер тоже годится?

     
     
  • 3.9, Аноним (9), 19:05, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Только линукс.
     
  • 3.10, Аноним (10), 19:12, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Не, ну если тебе нравится хэши запоминать и у тебя это хорошо получается, то можно и для других ядер тоже)
     
     
  • 4.11, Аноним (6), 19:14, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем их запоминать? Для удобства манипулирования их же можно сокращать до 8 первых символов, и даже в этом случае можно не запоминать.
     
  • 2.12, Аноним (12), 19:17, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Но другие свободные альтернативы распределённых VCS загнулись.
     
  • 2.13, Аноним (13), 20:06, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    CVS был топчик!
     
     
  • 3.17, Аноним (17), 20:31, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Отвратительным он был. Вздохнул с облегчением после перехода на гит.
     
  • 2.18, Аноним (18), 20:48, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Неиронично, но для совсем мелких или даже средних, банальное версионирование аля новая_папка2 внезапно неплохо справляется с задачей. Подход очень простой, старые версии архивируются, изменения в коде можно подписывать в отдельном файле.
     

  • 1.16, Аноним (16), 20:20, 18/11/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Скоро гит по количеству строк кода догонит ядро линукса
     
     
  • 2.19, Аноним (19), 20:58, 18/11/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если в гите завёлся раст - точно догонит.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру