Издаване на система за управление на изходния код Git 2.54

Представен е релиз на разпределената система за управление на изходния код Git 2.54. Git се отличава с висока производителност и предлага средства за нелинейно разработване, базирани на клониране и сливане на клонове. За осигуряване на целостта на историята и устойчивостта на измененията „задния ред“ се използват неявно хеширане на цялата предишна история в всеки комит, както и удостоверяване с цифрови подписи на разработчиците на отделни тагове и комити. Кодът на Git се разпространява под лицензия GPLv2+.

В сравнение с предишното издание, в новата версия са приети 770 изменения, подготвени с участието на 137 разработчици (66 от тях участват за първи път в разработката на Git). Основни нововъведения:

• Реализирана е команда „git history“, която предоставя експериментални възможности за пренаписване на историята на промените, по-лесни и безопасни за използване, отколкото повторното базиране на комити с командата „git rebase“. Предоставят се две операции:
  • „git history reword “ за пренаписване на съобщението в указан комит без да се променят работното дърво и индекса (с изключение на бележката, останалото остава непокътнато). Например, за коригиране на печатна грешка.
  • „git history split “ за интерактивно разделяне на указан комит на два различни комита с преместване на избрани части от изходния комит в допълнителен комит.

  В бъдещите издания се очаква добавяне на допълнителни команди: „git history fixup“ за коригиране на комит, „git history drop“ за изтриване на комит, „git history reorder“ за пренареждане на последователността на комитите и „git history squash“ за обединяване на комити.
• Внедрен е нов метод за определяне на обработчици (hook) в конфигурационните файлове. Вместо да се поставят скриптове с обработчици в директорията «.git/hooks» за всяко хранилище, командите за извикване на обработчиците сега могат да бъдат задавани директно в конфигурационните файлове. Настройките могат да бъдат свързани с хранилището или указани в конфигурационни файлове, действащи за всички хранилища (/etc/gitconfig) или за потребителски хранилища (~/.gitconfig). Възможна е свързаност на няколко обработчици с едно събитие. Скриптовете от «.git/hooks» все още продължават да се извикват, но се стартират след обработчиците от конфигурационните файлове. За преглед на списъка с обработчици следва да се използва командата «git hook list», а за селективно деактивиране на извикването на обработчици — настройката «hook..enabled = false». [hook «linter»] event = pre-commit command = ~/.bin/linter --cpp20 [hook «no-leaks»] event = pre-commit command = ~/.bin/leak-detector $ git hook list pre-commit global linter ~/.bin/linter --cpp20 local no-leaks ~/.bin/leak-detector
• В командата «git maintenance» по подразбиране е активирана стратегия «geometric» («git config set maintenance.strategy geometric»), която позволява да се съкрати времето за поддръжка на големи монорепозитории. В сравнение с предходната стратегия, използваща логика от командата «git gc», новата стратегия избягва повторното опаковане на всички обекти и изключва излишно ресурсоемките операции, като сливането на всички pack-файлове (по възможност обединението се извършва на части и без почистване на изтритите обекти).
• Базата данни на обектите (ODB) и свързаните с нея API-та са преминали към нова архитектура, основана на използването на плъгини. Проведената реструктуризация абстрахира формата на съхранение на обектите и в бъдеще ще позволи реализирането на такива възможности, като алтернативни бекенди и формати на обекти, например за по-ефективно съхранение на големи бинарни файлове или за оптимизация на работата на големи git хостинги.
• Командата «git repo structure» предоставя информация за структурата на хранилището, показвайки не само общия размер, но и най-големите обекти от всеки тип, което позволява оценката на размера да се извърши без използването на външния инструмент git-sizer. $ git repo structure … | * Най-големи обекти | | | * Комити | | | * Максимален размер [1] | 17.23 KiB | | * Максимален родител [2] | 10 | | * Дървета | | | * Максимален размер [3] | 58.85 KiB | | * Максимален брой записи [4] | 1.18 k | | * БLOB-ове | | | * Максимален размер [5] | 1019.51 KiB | | * Тагове | | | * Максимален размер [6] | 7.13 KiB |
• В командата «git replay», използвана вместо «git rebase» за възстановяване на историята на сървър без работно дърво, е включено по подразбиране атомно обновяване на референтите (вместо извеждане на списък с команди update-ref за ръчно изпълнение), реализирана е опция «—revert» за отмяна на промените от серия комити, осигурено е отхвърляне на резултантните празни комити и е предоставена възможност за възстановяване на историята до кореновия комит.
• В «git rev-list» и подобни команди е добавена опция «—maximal-only» за показване само на комитите, недостъпни от другите комити.
• В командата «git repo info» е добавена опция «—keys» за извеждане на списък с всички известни ключове.
• В командата «git add -p» при навигация между блоковете код с клавишите «J» и «K» е осигурено отбелязването на вече одобрените и пропуснати блокове. Добавена е опция «—no-auto-advance» за деактивиране на автоматичното преминаване към следващия файл, за да можете да се върнете към предишни файлове преди комит.
• Оптимизиране на уеб интерфейса «gitweb» за работа с мобилни устройства.
• В командата «git apply —directory» е осигурена нормализация на файловите пътища, като «. /un/.. /normalized/path» преди използването.
• Документирана е възможността за добавяне на собствени подкоманди чрез поставяне на файлове «git-» в директорията с изпълними файлове.
• В командата «git send-email» е добавена поддръжка за клиентски сертификати.
• За командата «git status» е реализирана настройка «status.compareBranches», през която можете да зададете клоновете, с които ще се извършва сравнение на текущия клон. [status] compareBranches = @{upstream} @{push}
• В «git rebase» е добавена опция «—trailer» за опростяване на добавянето на метаданни към всички комити. git rebase —trailer «Reviewed-by: Test »
• В команда „git fast-import“ беше добавена възможността за замяна на подписи на комити, които са станали невалидни след импорта.
• Добавена е поддръжка на компресиране (compaction) на многопакетни индекси MIDX (multi-pack index), при която се съединяват малки слоеве на MIDX индекса с информация за наличност на обекти и свързаните с тях bitmap файлове, което позволява намаляване на броя на натрупаните слоеве в стари хранилища.
• В командата „git backfill“ е реализирана възможността за указване на ревизии (диапазони на комити) и маски на пътища (pathspec) за ограничаване на зарежданите части от историята на промените. git backfill main~100..main git backfill — ‘*.c’
• Добавени са алтернативни форми за извикване на командата „git config list“ — „git config -l“ и „git config —list“.
• Разрешено е използването на не-ASCII символи в имената на псевдонимите на команди, зададени в конфигурационния файл. [alias „получавай“] command = fetch
• Променено е показването на подписи, чийто срок на действие на GPG ключовете е изтекъл, но които са били валидни в момента на подписване на комита. Тези подписи сега се показват като коректни с бележка за остарялост на ключа (по-рано те бяха обозначавани с червен цвят, което създаваше впечатление за некоректност).
• При достъп до хранилища по HTTP е осигурена обработка на грешка с код 429 (Too Many Requests). Завършилите с такава грешка заявки сега не се разглеждат като фатален проблем, а като временна грешка, за която след известно време следва да се повтори операцията. Забавянето преди повторение се задава с опцията „http.retryAfter“, броят на повторенията — „http.maxRetries“, времето на изчакване — „http.maxRetryTime“.

Източник: opennet.ru