Git готовится к 3.0: SHA-256 по умолчанию, reftable и обязательный Rust

Git держит мажорную версию 2.x с 2014 года, и за это время «второй гит» стал синонимом просто гита. Судя по обсуждению в списке рассылки, эта эпоха заканчивается: Юнио Хамано, сопровождающий проекта, в начале сентября задал прямой вопрос — выпускать ли следующей версию 3.0 или ещё раз отложить. Возражений, достаточно весомых, чтобы откладывать, не нашлось, так что тройка вполне может выйти до конца года.

Сначала, впрочем, выйдет 2.56 — в конце сентября. Релиз собран из более чем семисот немёрджевых коммитов, но по духу это спокойное накопительное обновление.

Что нового в 2.56

Самое заметное — подкоманда git history drop, которая удаляет выбранные коммиты и переигрывает поверх них остальную историю. Мёрдж-коммиты она пока не поддерживает, так что универсальным инструментом переписывания истории её называть рано, но для линейных веток это штатная замена связке из интерактивного ребейза и суеверий.

Семейство git refs обзавелось подкомандами create, delete, update и rename — то есть работа со ссылками перестаёт требовать update-ref и знания внутренностей. У git branch появился флаг --delete-merged, убирающий локальные ветки, уже влитые в свои удалённые аналоги: та самая уборка, которую все делают однострочником из чужого блога. У git add — флаг --resolved, который добавляет в индекс только файлы с разрешёнными конфликтами и при этом проверяет, не остались ли в них маркеры конфликта. git status теперь подсказывает git pull, если ветка отстала от отслеживаемой. И отдельно — улучшенная блокировка конфигурационных файлов при одновременном изменении: скучно, но именно такие вещи ломаются в скриптах и CI.

Что ломается в 3.0

Главный пункт — переход на SHA-256 по умолчанию. SHA-1, с которым Git живёт с первого дня, давно перестал считаться стойким, и для системы, где идентификатор объекта и есть гарантия целостности, это не академический вопрос. Неэкспериментальная поддержка SHA-256 появилась ещё в версии 2.42 в 2023 году, но массовый переход упирался в отсутствие поддержки на стороне GitHub: репозиторий, который некуда запушить, никому не нужен. Brian M. Carlson, работающий в GitHub и ведущий этот переход, дал понять, что поддержка на подходе. Существующие SHA-1-репозитории при этом продолжают работать — меняется значение по умолчанию для новых.

Второе изменение мельче, но заденет чужие скрипты: Git станет принимать идентификаторы объектов только в нижнем регистре. Сегодня f00f00 и F00F00 указывают на один и тот же коммит, и эта двусмысленность исправно порождает и баги, и уязвимости в инструментах, которые сравнивают хеши строками.

Третье — формат хранения ссылок. Вместо файлового хранилища, где каждая ветка это файл, по умолчанию будет reftable: бинарный формат, выигрывающий тем сильнее, чем больше в репозитории ссылок. Порядок величин задаёт пример Android с его восемьюстами тысячами рефов — там разница между «перебрать каталог» и «прочитать индекс» измеряется не процентами.

Четвёртое понравится не всем: для сборки Git понадобится рабочий компилятор Rust, причём на всех платформах. Дискуссия об этом в проекте шла давно, и аргумент против всегда был один — экзотические платформы, где Rust либо отсутствует, либо требует героизма. Решение принято в пользу тех, кто собирает Git на обычных системах.

Как это решается

Отдельно стоит процедурная часть. На вопрос о сроках Хамано ответил фразой, которую уже растащили на цитаты: это не конкурс популярности и даже не демократия. Сказано резко, но описывает реальность точно: Git по-прежнему управляется сопровождающим и списком рассылки, а не голосованием пользователей, и именно поэтому мажорное обновление с ломающими изменениями вообще оказалось возможным согласовать. Кэрлсон со своей стороны отметил, что крупные зависимые проекты о несовместимостях предупредили заранее.

Практический вывод для тех, кто держит инфраструктуру, простой и не требует паники. Если у вас есть скрипты, парсящие вывод Git, сверьте их на регистр хешей и на длину идентификатора: тридцать два байта SHA-256 в шестнадцатеричном виде — это 64 символа вместо привычных сорока, и всякая жёсткая проверка длины сломается. Если в вашей сборочной цепочке Git компилируется из исходников, добавьте в образ Rust. Если репозиторий большой и с тысячами веток, reftable стоит попробовать заранее, не дожидаясь смены умолчаний.

А вот менять формат хеша в существующих репозиториях никакой срочности нет: миграция остаётся отдельной операцией, а SHA-1 никто не выключает. Интереснее другое — впервые за двенадцать лет у проекта появился повод сказать «три», и список того, что за это время накопилось в очереди на ломающие изменения, оказался на удивление коротким и техничным.

Разбор с деталями обсуждения — в LWN.