The OpenNET Project / Index page

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

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

19.08.2025 07:09

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

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

  • Повышена производительность команд "git push" и "git fetch" в репозиториях с большим числом ссылок. Ускорение обеспечено за счёт обновления ссылок в пакетном режиме, в котором в одной транзакции обрабатывается сразу несколько ссылок, вместо создания отдельной транзакции для обновления каждой ссылки. Оптимизация существенно увеличила скорость работы бэкенда "reftable", которые теперь обгоняет по производительности бэкенд "files" Например, в тестовом репозитории с 10 тысячами ссылок производительность "git fetch" при использовании бэкенда "reftable" увеличилась в 22 раза, а при использовании бэкенда "files" - в 1.25 раза. Для "git push" прирост составил 18 и 1.21 раз, соответственно.
  • Предложен новый метод упаковки в pack-файлах частей репозитория, не связанных с отслеживанием недостижимых объектов, на которые в репозитории отсутствуют ссылки (не ссылаются ветки или теги). Информация о недостижимых объектах хранится в отдельных pack-файлах ("cruft packs"), что приводило к необходимости их отражения в многопакетных индексах MIDX (multi-pack index) для охвата объектов, которые изначально были недостижимы и хранились только в cruft-пакете, но затем стали достижимы после ссылающегося на них коммита.

    В новой версии при переупаковке pack-файлов обеспечено сохранение дополнительных копий достижимых объектов, хранимых только cruft-файлах. Подобное изменение гарантирует, что в наборе pack-файлов, используемых для хранения достижимых объектов, не содержится объектов, ссылающихся на другие объекты, хранимые вне этого набора. Для исключения из многопакетных индексов (MIDX) недостижимого содержимого cruft-файлов предложена настройка "repack.MIDXMustContainCruft", позволяющая заметно сократить размер подобных индексов. Включение настройки в репозитории GitHub позволило сократить размер MIDX-индексов на 38%, ускорить запись в MIDX-индексы на 35% и повысить производительность чтения на 5%.

  • В команду "git pack-objects" добавлена опция "--path-walk", включающая новый метод сбора информации об объектах при переупаковке pack-файлов. Вместо обхода объектов в порядке ревизий, при использовании режима "--path-walk" объекты перебираются через обход файловых путей, что позволяет разом упаковывать все объекты с одним и тем же файловым путём. Подобный подход даёт возможность исключить эвриситку, использующую хэширование для определения связи объекта с его файловым путём, а также избавиться от сортировки объектов перед упаковкой. При использовании режима "--path-walk" размер генерируемых pack-файлов получается значительно меньше, чем при группировке объектов при помощи хэшей.
  • Определён формат для обмена сохранёнными состояниями рабочего дерева и индексов в репозитории, создаваемыми при помощи команды "git stash". Новый формат позволяет кодировать сохранённые изменения (stash-записи) в виде последовательности коммитов. Для импорта и экспорта предложены подкоманды "git stash import" и "git stash export", которые можно использовать для переноса сохранённых состояний с одной системы на другую и выполнения операций push или pull с этими состояниями как с обычными ветками или тегами.
    
       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
    
  • В команде "git cat-file", выводящей содержимое заданных объектов, при использовании опций "--batch" и "--batch-check" реализована возможность отображения информации об отсутствующих объектах (например, из-за повреждения репозитория) и субмодулях. Ранее при указании пути у субмодулю команда "git cat-file --batch-check" выводила "missing", а теперь покажет идентификатор объекта.
  • В команде "git log" задействованы оптимизации на основе фильтров Блума для ускорения поиска в истории изменений при указании фильтров с несколькими файловыми путями, например, "git log -- path/to/a path/to/b".
  • Стабилизированы команды "git switch" и "git restore", которые с 2019 года рассматривались как экспериментальные. Команды преподносятся как современные эквиваленты "git checkout", разделяющие такие малосвязанные возможности данной команды, как манипуляция ветками (переключение и создание) и восстановление файлов в рабочем каталоге.
  • Объявлена устаревшей и намечена к удалению в ветке Git 3.0 команда "git whatchanged", эквивалентная "git log --raw".
  • В команду "git for-each-ref" добавлена опция "--start-after", которая может применяться совместно с опцией "--count" для организации постраничного вывода.
  • В команды "git merge" и "git pull" добавлена опция "--compact-summary" для использования компактного формата сводной информации об изменениях вместо формата diffstat.
  • В кодовой базе Git разрешено использование ключевого слова "bool", появившегося в стандарте C99. Также документированы некоторые возможности C99, экспериментально используемые в Git (например, в середине 2026 года планируют разрешить применение конструкций "(struct foo){ .member = value };"). Компилятор с поддержкой C99 является обязательным для Git c 2021 года, но возможности спецификации C99 внедряются крайне осторожно для сохранения совместимости с компиляторами, лишь частично поддерживающими данный стандарт.
  • В правила приёма патчей внесены изменения, разрешающие отправку патчей под псевдонимом, а не только под настоящим именем разработчика. Изменение соответствует правилам приёма патчей в ядро Linux.
  • Обновлён список нарушающих совместимость изменений, которые будут применены в ветке Git 3.0. Из значительных изменений в предстоящем выпуске Git 3.0 отмечается переход по умолчанию на идентификаторы объектов на основе алгоритма хэширования SHA-256 при инициализации новых репозиториев и задействование формата "reftable" для хранения в репозитории ссылок на ветки и теги (задействовано блочное хранилище от проекта JGit, оптимизированное для хранения очень большого числа ссылок).


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


Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, Аноним (6), 10:31, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Трудно представить большее Легаси.
     
     
  • 2.20, Аноним (20), 11:06, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Почему трудно? Легко, большее легаси это - cvs, svn, hg, perforce
     
     
  • 3.32, Аноним (-), 11:54, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему трудно? Легко, большее легаси это - cvs, svn, hg, perforce

    Ща я вас всех уделаю. Microsoft TFS (Team Foundation Server). Вот это я понимаю - легаси. VCS в котрой принципиально нельзя редактировать 1 и тот же файл, на уровне блокировок просто.

     
     
  • 4.35, mogwai (ok), 12:01, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >VCS в котрой принципиально нельзя редактировать 1 и тот же файл, на уровне блокировок просто

    В это время 1С с их Хранилищем конфигураций: "это почему это - легаси?"

     
  • 2.23, Аноним (-), 11:20, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Трудно представить большее Легаси.

    Что-то у тебя анон  плохо с фантазией. Bitbaker, perforce, cvs, svn. Hg, наконец.

     
     
  • 3.30, Аноним (30), 11:46, 19/08/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 4.31, Аноним (-), 11:52, 19/08/2025 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.7, Аноним (7), 10:31, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели компетенции не хватает, или же все жуют жвачку, только лишь потому что - мода такая?
     
     
  • 2.11, 52 (?), 10:36, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Из наиболее известного − репозиторий плеера qmmp работает на SVN, то есть не все используют git
     
  • 2.12, анонимас (?), 10:38, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    почему не используют сохранение по папкам с именами версий а хотят вендор-лок SVN ? неужто из за того что мода такая, а?
     
  • 2.13, Аноним (20), 10:38, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я думаю программисты не пользуются SVN потому git удобнее и фичастее, а еще он децентрализованный, а значитт позволяет работать со скаченными исходниками без подключения к Интернету.
     
  • 2.14, Аноним (14), 10:40, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >Почему программисты не пользуются SVN

    Потому что ушли с этого г-на на GIT и вспоминают этот кошмар как страшный сон.

     
     
  • 3.28, Аноним (-), 11:34, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что ушли с этого г-на на GIT и вспоминают этот кошмар
    > как страшный сон.

    Удваиваю этого анона. В жизни больше svn использовать не буду. В git можно девелопать как белый человек, хот 100% локально, быстро делать git bisect и что там еще - без постоянной выкачки половины проекта заново, что бывает мучительно тормозно если это не соседний сервак на гигабитной сетке.

     
  • 2.15, anonymous (??), 10:44, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты, видно, не очень часто работаешь с SVN, не знаешь, что такое ветки мержить в SVN.
     
  • 2.25, Аноним (25), 11:23, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Добрый день! Почему программисты не пользуются SVN, а пользуются вендор-локом GIT? Неужели
    > компетенции не хватает, или же все жуют жвачку, только лишь потому
    > что - мода такая?

    Я вот юзаю git на вон той репе с лично моим проектом - локально. Во я себя заведорлочил то. А в чем бенефит? А вот мне не надо ставить какие там сервера в обязаловку. Я пожалуй не против такого "вендорлока". Сам же и буду как единоличный вендор решать сколько живет моя приблуда.

    В качестве точки обмена в вебе опять же несложно гит нарулить. И в отличие от svn все копии репы равнопрравны и могут прекрасно наигировать по всей истории без того сервера. А в SVN на большом проекте нечто типа git bisect вообще задолбаешься нахрен делать, когда оно половину интернета выкачивает на каждую ревизию заново.

     
  • 2.29, Аноним (-), 11:43, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что:
    1) "мы тоже хотим быть как боги". Ну, то есть как разработчики ядра;
    2) гитхаб сделал git доступным для каждой домохозяйки

    Но всё же другие системы управления исходниками гораздо более для людей, главное не сужать свой кругозор до SVN.

     
     
  • 3.33, Аноним (-), 11:55, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Но всё же другие системы управления исходниками гораздо более для людей,

    Не стоит путать ящеров, домохозяек и домохозяек-ящеров с людьми.

     

  • 1.10, 52 (?), 10:33, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    То что git написан в основном на C90 показывает какой git капролит
     
     
  • 2.16, Аноним (6), 10:47, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Единственный нормальный комментарий во всей ветке.
     
     
  • 3.21, Аноним (21), 11:12, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    4 ошибки в одной строке текста опровергают Вашу гипотезу.
     
  • 2.18, Обычный человек (?), 10:50, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Расскажите, что написано не на Си или не использует либы написанные не на Си, и при этом не копролит? Будем вместе с вами переходить не на копролит.
     
     
  • 3.22, Аноним (21), 11:13, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Квалификация позволяет.
     
  • 2.26, Аноним (-), 11:24, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > То что git написан в основном на C90 показывает какой git капролит

    А то что ты даже "копролит" правильно написать не можешь - показывает уровень. Это от слова copr - как там его федора расшифровывает. Шутка, но в каждой шутке... :)

     

  • 1.24, Аноним (24), 11:22, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >отмечается переход по умолчанию на идентификаторы объектов на основе алгоритма хэширования SHA-256

    А протокол передачи на remote и поддержку в forge-ах они реализовали? Или предлагают перейти на воркфлоу с патчами, как в ядре linux?

     
     
  • 2.27, Аноним (-), 11:25, 19/08/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > А протокол передачи на remote и поддержку в forge-ах они реализовали? Или
    > предлагают перейти на воркфлоу с патчами, как в ядре linux?

    Куды эти форжи денутся? Запилят как зайчики.

     

  • 1.34, Анон28679234 (?), 11:58, 19/08/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня это какой-то лютый когнитивный диссонанс вызывает

    С одной стороны это backbone всей it индустрии и я этим отличным инструментом пользуюсь каждый день на 110%.

    С другой стороны в этой версии разрешили использовать стандарт которому не 35 лет, а всего 25(!) и то только частично

    Буквально пару версий назад писали что наконец-то git по окончании своей работы не тупо забивает на очистку памяти а правильно освобождает память как положено. И мол именно это блочило git от того чтобы завернуть его в dll и поставлять в таком виде всяким приложениям с gui потому что если консольное приложение в конце теч'т, то как бы пофиг, но для dll это проблема.

    Как так вышло что то что является фундаментом качественного кода и принципиально важной вещью, для разработчиков git всего лишь несущественная рекомендация которую начали соблюдать только потому что есть план заворачивать это все в dll ¯\_(ツ)_/¯

    Читать git release notes - это для смелых духом

     

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



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

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