Пускане на системата за управление на изходния код 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-та са прехвърлени на нова архитектура, основана на използването на плъгини за backend. Проведената реструктуризация абстрахира формата на съхранение на обектите и в бъдеще ще позволи реализирането на такива възможности, като алтернативни backend-и и формати на обекти, например за по-ефективно съхранение на големи бинарни файлове или за оптимизация на работата на големи 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-<cmd>» в директорията с изпълняемите файлове.
• В командата «git send-email» е добавена поддръжка за клиентски сертификати.
• За командата «git status» е реализирана настройка «status.compareBranches», чрез която може да се уточнят клоновете, с които ще се сравнява текущият клон. [status] compareBranches = @{upstream} @{push}
• В «git rebase» е добавена опция «—trailer» за опростяване на добавянето на метаданни към всички комити. git rebase —trailer «Reviewed-by: Test <test@example.com>»
• В командата „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