Издаването на Git 2.55 с включване по подразбиране на поддръжка за Rust

Представен е релиз на разпределената система за управление на изходни текстове Git 2.55. Сред основните промени: включване по подразбиране на компилация с Rust, реализация на fsmonitor за Linux, нова стратегия за повторно опаковане на инкременталния MIDX индекс, команда „git history fixup“ за коригиране на комит, оптимизация на генерирането на битови карти за достъпност на обектите, поддръжка на паралелно изпълнение на hook-ове и команда „git format-rev“. Кодът на Git се разпространява под лиценз GPLv2+.

Сравнено с предходния выпуск, в новата версия са приети 505 изменения, подготвени с участието на 100 разработчици, 33 от които взимат участие в разработката на Git за първи път. Основни нововъведения (1, 2, 3):

• По подразбиране е включена поддръжката за компоненти на Rust. Компилаторът rustc
  е добавен в списъка на зависимостите за компилация. За компилация без Rust може да се използва флага „NO_RUST=1“ при стартиране на утилитата make или „-Drust=disabled“ при изпълнение на „meson configure“. Възможността за деактивиране на компилацията с Rust ще се поддържа до версия Git 3.0, в която Rust ще стане задължителна зависимост. На Rust е реализирана прослойка за преносимост между конфигурации с хешове SHA-1 и SHA-256, а също и някои вътрешни функции, като кодиране и декодиране на цели числа с променлива дължина. В бъдеще се очаква значителна переправка на вътрешни компоненти на Git на Rust.
• В експерименталната команда „git history“, която предоставя възможности за пренаписване на историята на измененията, е добавена операцията „git history fixup“ за коригиране на комит. Операцията „fixup“ позволява прехвърляне на изменения, добавени чрез „git add“, в по-ранен комит и автоматично пренаписване на всички последващи комити, подобно на изпълнението на командата „git commit —fixup=“ и стартиране на „git rebase —autosquash ~“.
• За платформата Linux е реализиран фонов процес fsmonitor, който следи за изменения в файловата система с помощта на механизма inotify и позволява да се избегне обхождането на целия работен каталог при изпълнението на команди като „git status“. Включването се осъществява чрез настройката „core.fsmonitor“.
• В командата «git repack» е добавен режимът «—write-midx=incremental», реализиращ нова стратегия за обновление на метаданните в инкременталния MIDX индекс (multi-pack index), позволяваща да се заобиколи повторното опаковане на целия индекс. В инкременталния многопакетен индекс вместо един голям индекс, съдържащ информация за разпределението на обектите по pack файлове, се прилага разделяне на слоеве — всеки слой обхваща определен брой pack файлове и се съхранява в отделен bitmap файл. Подобна структура позволява да се добавят данни за обектите в нови pack файлове, прикрепяйки нови слоеве към индекса без да се пренастройват вече съществуващите слоеве.

  Командата «git repack —write-midx=incremental» позволява да се добави нов слой към инкременталния MIDX индекс, обхващащ наскоро създадени pack файлове. В комбинация с режима за опаковане на репозитории «—geometric», новата команда предоставя възможност да се обединят новите обекти от няколко pack файла в един по-голям pack файл и при необходимост да се извърши опаковане и сливане на няколко съседни слоя от инкременталния MIDX индекс. Подобна стратегия позволява при изпълнението на «git repack» да се препишат само горните слоеве, оставяйки старите големи слоеве непокътнати, а също така да се предотврати неконтролирано увеличаване на веригата от слоеве, поддържайки общия брой слоеве на ниво, пропорционално на логаритъма на общия брой обекти.

• Значително е оптимизирана генерацията на битови карти за достъпност на обектите благодарение на нов алгоритъм за обход на дървото от обекти, който изключва излишната рекурсия, кешира позициите на обектите, сортира битовите карти преди тяхното обединение с операцията XOR и преработва кода за създаване на битови карти за псевдосливане (pseudo-merge). В тестовото хранилище оптимизациите позволиха да се намали времето за генериране на битови карти от 612 на 294 секунди.
• Реализирана е възможността за паралелно изпълнение на независими хукове в конфигурационните файлове. Хуковете, които влияят на общото състояние или го отчетат, като например, променящи коментарите към комитите или инспектиращи индексите и работното дърво, не могат да се изпълняват паралелно. Въпреки това, хуковете, които проверяват с линтера и изпълняват unit-тестове, могат да се стартират паралелно. Хуковете, допускащи паралелно изпълнение, се конфигурират чрез параметъра «hook.име_хука.parallel = true». Броят на работите, които могат да се стартират едновременно, се определя чрез настройките hook.jobs, hook..jobs или опцията за командния ред «-j».
• В командата «git pack-objects —path-walk» е реализирана възможността за указване на филтри като «blob:none», «blob:limit=», «tree:0», «object:type=», «sparse:» и «combine:». В проведен тест, отхвърлянето на блоби при изпълнение на «—path-walk» е позволило да се намали размерът на формирания pack-файл с 16%.
• Добавена е команда «git format-rev» за форматиране на ревизии и имена на обекти, споменати в списъците с комити или срещащи се в произволен текст (например, може да се използва в хукове за обработка на коментарите на комитите).

  git last-modified | git format-rev —stdin-mode=text —format=%an

  Junio C Hamano builtin/commit.c

• По подразбиране е активирано екранирането на повечето последователности за управление на терминала в информационните съобщения и текста на грешките, предавани сървъра.. При взаимодействие с злонамерен сървър такива escape-последователности могат да се използват за скриване или модифициране на изхода, например, чрез escape-последователности за движение на курсора и почистване на текста. Подкрепата на escape-последователности за оцветяване на елементите е запазена.
• Командата «git checkout -m» вече автоматично запазва конфликтуващите локални промени в stash-областта, без нужда от незабавно разрешаване на конфликта.
• В командата «git push» е добавена възможността да се поставят клонове на няколко външни Git-сървъра с една команда. Например, за предаване на клона main не само на основния сървър, но и на огледала, може да се създаде група «publish» от сървъри «github», «gitlab» и «mirror»:

  git config remotes.publish «github gitlab mirror»
  git push publish main

• В командата «git log —graph» е добавена опцията «—graph-lane-limit=» за ограничаване на броя на вертикалните ленти при визуализация на клоновете, което позволява оставянето на място на екрана за данни за комитите в хранилища с голям брой клонове.

  …
  * | | | | 619931f561 Merge branch ‘dl/posix-unused-warning-clang’
  |\ \ \ \ \
  | * | | | ~ cf48887610 compat/posix.h: опростяване на GIT_GNUC_PREREQ() сравнение
  | * | | | ~ ffd45926dc compat/posix.h: почистване на GIT_GNUC_PREREQ() и UNUSED
  |\ \ \ \ \~
  | * | | | ~ 3f5203eeb4 ls-files: филтриране на pathspec преди lstat

• В командите «git log» и «git rev-list» е добавена опцията «—max-count-oldest=, която позволява да се изберат N най-стари комити в диапазона.

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