mergiraf — инструмент, ориентиран към AST за тройно сливане в Git

Публикуван е релиз на проекта mergiraf 0.4, който развива драйвера за Git с реализирана възможност за тройно сливане. Mergiraf поддържа разрешаването на различни видове конфликти при сливане и може да се използва за различни езици за програмиране и формати на файлове. Възможно е както отделно извикване на mergiraf за обработка на конфликти, възникващи при работа с редовния Git, така и замяна на Git обработвача на сливания, за да се разширят възможностите на команди като merge, revert, rebase и cherry-pick. Кодът се разпространява под лицензия GPLv3. В новата версия е добавена поддръжка за езици Python, TOML, Scala и Typescript, а също така е проведена оптимизация на производителността.

По-долу е представено подробно описание на проблемите, които се решават с помощта на mergiraf:

Софтуерът е ярък пример за изключително сложна система. Сложните системи имат едно общо свойство — те са СЛОЖНИ — и не можете да очаквате, че необходимо сложното поведение ще възникне само по себе си, случайно. Вместо това тези системи еволюират с времето, стъпка по стъпка, и всяка мутация се проверява внимателно на всеки етап. За да се постигне това, са необходими добре дефинирана структура и подходящи инструменти. Еволюцията на всяка сложна система може да се визуализира под формата на насочено дърво, където коренът представлява празен набор от функции, а всеки възел — с изключение на корена — е резултат от прилагане на мутация към своя родител.

В контекста на продуктите всеки възел се нарича "версия", представляваща определен набор от функции и антифункции. Всяка промяна в този набор се счита за мутация, която формира ребро в нашия насочен ацикличен граф. Тези функции по същество са абстрактни; те не отразяват директно начините на функциониране на физическите системи, а по-скоро демонстрират как разумни агенти възприемат полезността на тези системи. За да се преведат идеите в съществуващи в реалния свят реализации, е необходимо да се засучат ръкави и да се потопим в *достатъчно* нискоуровневите детайли, на език, на който можем да изразим и обясним как точно всичко работи. В разработката на софтуер тези нискоуровневи детайли обикновено са представени от изходен код.

За да доведат изходния код до състояние, изразяващо желаното поведение, и да документират как са стигнали до него, програмистите представят своята работа в термини на snapshot и changeset. Snapshot представлява определено състояние на продукта с всички нискоуровневи детайли, докато changeset означава преход между snapshot-ите. Обикновено snapshot-ите се генерират от индивидуални changeset-ове спрямо техните родителски, поради което тези snapshot-ове почти винаги са маркирани с действията на changeset-ите, които ги създават, и затова тези термини често се използват взаимозаменяемо.

Понякога съществуват снимки, получени в резултат на няколко прехода — сливане на комити. Те са трудни за работа, затова обикновено се избягват. Съвременните системи за контрол на версиите с отворен код, като Git, предлагат доста основни възможности за управление на работните потоци на разработката. Те позволяват на разработчиците да организират снимките под формата на насочени ациклични графове, да ги анотират с коментари и при необходимост да променят тяхната последователност.

Тази функционалност позволява на разработчиците да пишат семантично значима история на проекта, което е решаващо за отстраняване на проблеми и отговори на въпроси като „Защо беше въведен този нискоуровневен детайл (например, променлива)?“, „Колко процента е моят принос в този проект?“, „Кого хакнаха внедряванията на бекдор и кога?“, „Какво нискоуровнево изменение счупи тази функция (въпреки че не би трябвало да е така, ние всичко проверихме!?)"

Системите за контрол на версиите допълват концепцията за клонове — ниско ниво понятие, което просто означава непрекъснат фрагмент от историята на проекта, семантично значим за разработчика. Обикновено клоновете се използват за конкретна реализация на функции, като понякога се създават няколко клона за различни кандидати за реализация на една и съща функция. Използвайки работни потоци с клонове (което всъщност е мейнстрийм и стандарт в разработката, използва се навсякъде), всеки отделен разработчик може ефективно да управлява многобройни конфликтни клонове на проекта, всеки от които се различава по степен на готовност или качество. Това позволява на разработчиците да комбинират резултатите от своя труд и чуждата работа без да презаписват всичко на ръка всеки път.

Обикновено се създава основен клон, представляващ "официалния" продукт, от който се разклоняват странични клонове за всяка функция, които редовно (в идеалния случай — след всяко комитване) се синхронизират с основния клон, което позволява на разработчиците да работят с последната версия на продукта и в същото време да внедряват функции, които в момента разработват, откривайки проблеми, произтичащи от действията на други разработчици, колкото се може по-рано.

При опит за комбиниране на функции от различни snapshot-ове (което е просто намиране на общ предшественик и последователно прилагане на changeset-ите, които ги извеждат, върху друг, тази операция се нарича rebase, докато сливането е почти като rebase, просто структурира графа на комитите по различен начин, в резултат на което става неудобно да се манипулира с тях, затова се стараят да се откажат от сливания в полза на rebase-ове) възникват проблеми. Съвременните системи за контрол на версиите (VCS) използват вътрешни алгоритми за комбиниране на изменения, които просто разбиват файловете на отделни редове, разглеждат всеки ред като символ, а файловете — като последователности от тях, и след това прилагат алгоритми за комбинирането им, произхождащи от биоинформатиката.

За съжаление, това построчно представяне на изходния код не отразява съдържанието му. Единственото му предимство е, че е прост и универсален. Несъответствията водят до конфликти, причинявайки постоянно главоболие за разработчиците. Разрешаването на конфликти изисква от разработчика внимателно да проучи и двете версии на кода, и то не само разделите, обозначени от построчния алгоритъм за сравнение като „променени“ или „конфликтуващи“, но може би и целия проект.

Разработчикът трябва да разбере промените, ръчно да напише обединен код и да отстрани всякакви несъответствия. Проблемите значително се увеличават, когато постречният инструмент неправилно идентифицира промените, което често се случва при големи изменения, включително тривиални, като например форматирането на кода. Ако последващи промени не могат да бъдат приложени към ръчно обединения код, ситуацията става пълен кошмар. Въпреки ужасните случаи, в повечето случаи построчният алгоритъм работи, особено ако разработчиците активно се опитват да не създават проблеми. Един от начините за минимизиране на подобни проблеми е задължителното изискване за обработка на изходниците с инструменти за каноникализация, като black.

Разбира се, правилното решение на ужасни случаи (и изобщо, не само за тях, построчният алгоритъм е хевристика, която може тривиално да доведе до неработещ код; например, един разработчик е преименувал променлива, а друг е написал нов код, който използва тази променлива, конфликт на сливане/пребазиране няма да има, но резултатът ще стане неработещ) е използването на правилния вътрешен модел.

Въпреки че изследванията в тази област продължават вече около 30 години и доведоха до създаването на няколко проприетарни търговски продукта, тези изследвания доскоро не бяха превърнати в практически приложими продукти с отворен код. Основната част от решенията с отворен код започна да се развива в началото на 2010-те години и беше изцяло фокусирана върху езика Java.

Най-значимата свободна реализация от този период, GumTree, е създадена от изследовател с академичен фон, написана на Java и има своето абстрактно вътрешно представяне, предшестващо treesitter. Тя разполага с бекенди както на базата на treesitter, така и на други инструменти за парсинг на изходен код в абстрактни представяния. Тази система може само да генерира (под формата на текстов журнал на събития, както и да предоставя API, което може да бъде извикано от всеки ЯП, който има биндинги за Java) и да визуализира промените. Въпреки това, тя не е приложима директно за сливането на промени или за преглед на генерираните от нея diff-файлове (въпреки че вероятно е възможно да се реализира зареждане на diff-ове чрез API).

По-младата и по-подходяща за практическо приложение реализация difftastic е написана на Rust, базирана на treesitter и се фокусира върху генерирането на подсветени diff-ове в конзолата. Тази система също така е насочена към визуализация на diff-ове и изобщо не си поставя за цел сливането на промени или прилагането на пачове.

Съвсем наскоро се появи и активно се развива проектът mergiraf. Този инструмент, написан на Rust (зает е 21 MiB!), също е базиран на treesitter, който вече се е утвърдил като стандарт за парсери на контекстно-свободни граматики в инструментите за разработка, подобно на LLVM за оптимизация на нискоуровневите представяния на инструкции. В отличие от конкурентите си, mergiraf предоставя функции не за генериране на diff-ове, а за автоматично разрешаване на конфликти при сливане. Под капака, mergiraf използва реализация на алгоритъм, използван в GumTree, за генериране на пачове и реализация на алгоритъм, използван в spork, адаптирани към структури treesitter, за прилагане.

Сериализация на пачове в файлове, които могат да бъдат приложени по-късно, за съжаление не е реализирана (но е напълно вероятно да бъде реализирана чрез парсинг на логовете на събития, генерирани от GumTree). Друг перспективен начин за прилагане на различия може да бъде чрез функционалността за рефакторинг на LSP-сървърите, което може да помогне за откриване на конфликти на ниво цял проект. Визуализацията се поддържа само за конфликти.

Пример на работа: общ родител "base.py" (отстъпки табове, излишен ред в началото) foo = 1 def main(): print(foo + 2 + 3) "a.py" (отстъпките все още са табове, 2 излишни реда в началото вместо един, за отладъчния печат е използвана библиотеката icecream, добавен е клас "baz": from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) клас baz: def __init__(self): """baz""" "b.py" (променливата "foo" е преименувана на "bar", обработена с "black" след промените, в резултат отстъпките са с празни символи и излишните редове са изрязани): bar = 1 def main(): print(bar + 2 + 3) Визов .\/mergiraf merge .\/base.py .\/a.py .\/b.py -x a.py -y b.py -s base.py -o .\/res.py дава следния резултат from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) клас baz: def __init__(self): """baz""" (за отладъчния печат е използвана библиотеката "icecream", променливата "foo" е преименувана на "bar", обработена с "black" след промените, в резултат отстъпките са с празни символи и излишните редове са изрязани, смес от табове и празни символи за отстъп, но одобрен вид).

Тук се вижда недостатък на инструмента. Стилът на документа обикновено се конфигурира в файлове " .editorconfig ", и глобалните промени в стилa, като смяна на табове с празни символи и приемане на стилa на black-а, както е направено в "b.py", обикновено съпровождат промени в " .editorconfig ". Следователно, за по-точно прилагане на подобни промени инструментът трябва да има концепция за глобален стил "по подразбиране" и да може да извлече настройки от " .editorconfig ".

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