mergiraf - AST-ориентирана тринасочна алатка за спојување во Git

Објавено е објавувањето на проектот mergiraf 0.4, развивајќи драјвер за Git со имплементација на можноста за тринасочно спојување. Мергираф поддржува разрешување на разни видови конфликти со спојување и може да се користи за различни програмски јазици и формати на датотеки. Можно е или да се повика mergiraf одделно за да се справи со конфликтите што се јавуваат при работа со стандардниот Git или да се замени управувачот со спојување во Git за да се прошират можностите на командите како што се спојување, враќање, пребазирање и избор на цреши. Кодот се дистрибуира под лиценцата GPLv3. Новата верзија додава поддршка за јазиците Python, TOML, Scala и Typescript, како и оптимизација на перформансите.

Подолу е детален опис на проблемите решени со помош на мергираф:

Софтверот е одличен пример за исклучително сложен систем. Сложените системи имаат едно заедничко - тие се КОМПЛЕКСНИ - и не можете да очекувате сложеното однесување што сакате да се случи случајно. Наместо тоа, овие системи се развиваат со текот на времето, чекор по чекор, и секоја мутација е внимателно тестирана во секоја фаза. За да се постигне ова, потребна е добро дефинирана структура и соодветни алатки. Еволуцијата на кој било комплексен систем може да се визуелизира како насочено дрво, каде што коренот е празен сет на функции и секој јазол - освен коренот - е резултат на примена на мутација на неговиот родител.

Во контекст на производите, секој јазол се нарекува „верзија“, што претставува специфичен сет на функции и анти-функции. Секоја промена на ова множество се смета за мутација, формирајќи раб во нашиот насочен ацикличен график. Овие функции се инхерентно апстрактни; тие директно не ги одразуваат начините на кои функционираат физичките системи, туку демонстрираат како интелигентните агенти ја перципираат корисноста на тие системи. За да ги преведете идеите во имплементации во реалниот свет, треба да ги засукате ракавите и да се нурнете во *доволно* детали на ниско ниво што можат да изразат и да објаснат точно како функционираат работите. Во развојот на софтвер, овие ниско ниво обично се претставени со изворен код.

За постепено да го доведат нивниот изворен код во состојба што го покажува посакуваното однесување, и да документираат како дошле таму, програмерите ја претставуваат нивната работа во смисла на снимки и промени. Снимката претставува специфична состојба на производот со сите детали на ниско ниво, додека комплетот за промени претставува премин помеѓу снимките. Вообичаено, снимките се создаваат од единечни множества на промени на нивните родители, така што овие снимки скоро секогаш се означени дека ги прават сетовите на промени што ги создале, така што термините често се користат наизменично.

Понекогаш има снимки добиени како резултат на неколку транзиции - обврзници за спојување. Тешко е да се работи со нив, па обично се избегнуваат. Современите системи за контрола на верзијата со отворен код, како што е Git, обезбедуваат многу основни способности за управување со развојните работни текови. Тие им овозможуваат на програмерите да организираат снимки како насочени ациклични графикони, да ги прибележат со коментари и да ги прередуваат по потреба.

Оваа функционалност им овозможува на програмерите да напишат семантички значајна историја на проектот, што е критично за отстранување грешки и одговарање на прашања како „Зошто беше воведен овој детал на ниско ниво (на пр. променлива)?“, „Приближно колкав процент од мојот придонес во овој проект е ?“, „Кој беше хакиран од имплементации на обележувачи и кога?“, „Која промена на ниско ниво ја прекина оваа функција (иако се чини дека не требаше, проверивме сè!?)“

Системите за контрола на верзиите го надополнуваат ова со концептот на гранка, концепт на ниско ниво што едноставно значи соседен дел од историјата на ниско ниво на проект што е семантички значајно за развивачот. Гранките обично се користат за специфични имплементации на карактеристики, понекогаш се создаваат повеќе гранки за различни кандидатски имплементации на истата карактеристика. Користејќи разгранувачки работни текови (кои се практично мејнстрим и стандард за развој, кои се користат насекаде и секаде), секој поединечен развивач може ефективно да управува со многу конфликтни гранки на проектот, од кои секоја се разликува по зрелост или квалитет. Ова им овозможува на програмерите да ги комбинираат резултатите од сопствената и туѓата работа без да создаваат сè рачно секој пат.

Вообичаено, се создава главна гранка што го претставува „официјалниот“ производ, од кој страничните гранки се разгрануваат за секоја карактеристика, кои редовно (идеално по секое извршување) се синхронизираат со главната гранка, дозволувајќи им на програмерите да работат со најновата верзија на производот и истовремено ги имплементираат карактеристиките што тие ги сакаат во моментов се развиваат со откривање на проблеми што произлегуваат од активностите на другите програмери што е можно порано.

Кога се обидувате да ги комбинирате функциите на различни снимки (што е едноставно пронаоѓање заеднички предок и примена на сетови за промени кои ги генерираат, последователно врз друга, оваа операција се нарекува rebase, спојувањето е речиси како rebase, тоа само го структурира извршувањето графикони поинаку, како резултат на што им е незгодно да манипулираат, па се обидуваат да ги напуштат спојувањата во корист на пребазовите) се појавуваат проблеми. Современите системи за контрола на верзии (VCS) користат алгоритми за спојување на внатрешни промени кои едноставно ги делат датотеките на поединечни линии, ја третираат секоја линија како знак и датотеките како нивни секвенци, а потоа применуваат алгоритми за да ги спојат што доаѓаат од биоинформатиката.

За жал, ова претставување линија-по-линија на изворниот код нема никаква врска со неговата содржина. Неговата единствена предност е што е едноставна и универзална. Недоследноста води до конфликти, што е постојан извор на главоболки за програмерите. Решавањето на конфликти бара од развивачот внимателно да ги проучи двете верзии на кодот, не само деловите назначени од алгоритмот за споредба линија-по-линија како „променети“ или „конфликтни“, туку можеби и целиот проект.

Програмерот мора да ги разбере промените, рачно да го напише споениот код и да ги реши сите недоследности. Проблемите стануваат уште попроблематични кога алатката линија по линија погрешно ги идентификува промените, што често се случува со големи промени, вклучително и тривијални, како што е реформатирање на кодот. Ако последователните промени не можат да се применат на рачно споениот код, ситуацијата станува целосен кошмар. И покрај ужасните случаи, алгоритмот линија-по-линија работи поголемиот дел од времето, особено ако програмерите активно се обидуваат да не му прават проблеми. Еден начин да се минимизираат ваквите проблеми е да се бара да се обработуваат изворните кодови со алатки за канонализација, како што е црната боја.

Се разбира, правилното решение за ужасни случаи (и воопшто, не само за нив, алгоритмот линија по линија е хеуристички, може тривијално да доведе до скршен код, на пример, еден развивач преименувал променлива, а друг во во исто време напиша парче нов код користејќи ја таа променлива, конфликт нема да има спојување/ребазирање овде, но резултатот ќе стане неработен) - ова е употребата на правилниот внатрешен модел.

И покрај фактот дека истражувањето во оваа област трае околу 30 години и резултираше со создавање на неколку комерцијални комерцијални производи, ова истражување до неодамна не беше претворено во практични производи со отворен код. Најголемиот дел од софтверските решенија со отворен код почнаа да се развиваат во раните 2010-ти, и беа фокусирани главно на јазикот Јава.

Најистакнатата бесплатна имплементација од тој период, GumTree, е создадена од истражувач со академско потекло, напишана на Java, има своја апстрактна внатрешна претстава која што претходи на чуварот на дрвја и има заднински засновани на дрвоседавач и засновани на други алатки за парсирање на изворот код во апстрактни претстави. Овој систем може само да генерира (во форма на дневник за текстуални настани; исто така постои и API што лесно може да се повика од кој било јазик што има врски за Java) и да ги визуелизира промените. Сепак, за спојување на промените, како и за прегледување на различни датотеки генерирани од него, тоа не е применливо надвор од кутијата (сепак, веројатно е дека разликите за вчитување може да се имплементираат преку API).

Помлада и попрактична имплементација на difftastic е напишана во Rust, базирана на чувар на дрвја и е фокусирана на генерирање на истакнати разлики во конзолата. Овој систем исто така е насочен кон визуелизирање на разликите и генерално нема за цел да ги спојува промените или да применува закрпи.

Проектот мержираф неодамна се појави и активно се развива. Оваа алатка, напишана во Rust (21 MiB!), исто така се заснова на чувар на дрвја, кој стана стандард за граматички анализатори без контекст во развојните алатки како што стана LLVM за оптимизирање на репрезентации на ниско ниво. За разлика од своите конкуренти, mergiraf обезбедува функции не за генерирање разлики, туку за автоматско решавање на конфликти за спојување. Под хаубата, mergiraf користи имплементација на алгоритмот што се користи во GumTree за да генерира лепенки, а за примена, имплементација на алгоритмот што се користи во spork, прилагоден за структурите на чувари на дрвја.

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

Пример на работа: заеднички предок „base.py“ (вовлечени картички, дополнителна линија на почетокот) foo = 1 def main(): print(foo + 2 + 3) „a.py“ (вовлечени картички, 2 дополнителни линии на почетокот, наместо една, библиотеката за сладолед се користи за печатење за отстранување грешки, се додава класата „baz“: од увоз на сладолед ic foo = 1 def main(): ic(foo + 2 + 3) класа baz: def __init__(self): """baz"" "b.py" (променлива "foo" преименувана во "bar", обработена со "црна" по промените, што резултира со вовлекување со празни места и дополнителни линиите се сечат): лента = 1 дефиниција main(): печатење(лента + 2 + 3) Повикај ./mergiraf merge ./base.py ./a.py ./b.py -x a.py -y b.py -s base.py -o ./res.py го дава следниот резултат од увоз на сладолед ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__ (self): """baz""" (за печатење за отстранување грешки, се користи библиотеката "icecream", променливата "foo" се преименува во "bar", се обработува со "црно" по промените, што резултира со вовлекување — отсечени празни места и дополнителни линии, мешавина од јазичиња и празни места за вовлекување, но дозволената форма).

Недостигот на алатка е веднаш видлив. Стајлирањето на документите обично се конфигурира во датотеките .editorconfig, а глобалните промени во стилот, како што се менување на јазичиња во празни места и прифаќање на црниот стил како што е направено во b.py, обично се придружени со промени во .editorconfig. Затоа, за поправилна примена на таквите промени, алатката мора да има концепт за глобален „стандарден“ стил и да може да ги повлекува поставките од „.editorconfig“.

Извор: opennet.ru