De release van het mergiraf-project 0.4 is uitgebracht, dat een stuurprogramma voor Git ontwikkelt met de mogelijkheid voor driedimensionale samenvoeging. Mergiraf ondersteunt het oplossen van verschillende soorten conflicten bij samenvoegingen en kan worden gebruikt voor verschillende programmeertalen en bestandsformaten. Het is mogelijk om mergiraf afzonderlijk aan te roepen voor het verwerken van conflicten die ontstaan bij het gebruik van standaard Git, evenals om de merge-handler in Git te vervangen om de mogelijkheden van commando's zoals merge, revert, rebase en cherry-pick uit te breiden. De code wordt verspreid onder de GPLv3-licentie. In de nieuwe versie is ondersteuning toegevoegd voor de talen Python, TOML, Scala en Typescript, en is de prestatie geoptimaliseerd. <\/p>\n
Hieronder volgt een gedetailleerde beschrijving van de problemen die met mergiraf worden opgelost: <\/p>\n
Software is a striking example of an extremely complex system. Complex systems share a common trait \u2014 they are COMPLEX \u2014 and you cannot expect the necessary complex behavior to emerge on its own, by chance. Instead, these systems evolve over time, step by step, and each mutation is carefully checked at every stage. Achieving this requires a well-defined structure and appropriate tools. The evolution of any complex system can be visualized as a directed tree, where the root represents an empty set of functions, and each node \u2014 except for the root \u2014 is the result of applying a mutation to its parent. <\/p>\n
In the context of products, each node is called a \u2018version,\u2019 representing a specific set of functions and anti-functions. Any change to this set is considered a mutation, forming an edge in our directed acyclic graph. These functions are inherently abstract; they do not directly reflect the ways physical systems operate, but rather demonstrate how rational agents perceive the utility of these systems. To translate ideas into existing real-world implementations, you need to roll up your sleeves and dive into *sufficiently* low-level details, in a language that can express and explain exactly how everything works. In software development, these low-level details are usually represented by source code. <\/p>\n
Om de broncode geleidelijk in de toestand te brengen die het vereiste gedrag vertoont en te documenteren hoe ze dat hebben bereikt, presenteren programmeurs hun werk in termen van snapshots en changesets. Een snapshot vertegenwoordigt een bepaalde staat van het product met alle gedetailleerde laag-niveau informatie, terwijl changeset de overgang tussen snapshots aanduidt. Gewoonlijk worden snapshots voortgebracht door enkele changesets naar hun ouders, dus deze snapshots worden bijna altijd gemarkeerd door wat changesets hebben gedaan die ze hebben gecre\u00eberd; daarom worden deze termen vaak door elkaar gebruikt. <\/p>\n
Sometimes there are snapshots created as a result of several passes \u2014 merging commits. They are difficult to work with, so they are usually avoided. Modern open-source version control systems, such as Git, provide very basic capabilities for managing software development workflows. They allow developers to organize snapshots as directed acyclic graphs, annotate them with comments, and change their order if necessary. <\/p>\n
Deze functionaliteit stelt ontwikkelaars in staat om een semantisch significante projectgeschiedenis te schrijven, wat essentieel is voor het debuggen en het beantwoorden van vragen zoals: 'Waarom is dit low-level detail ge\u00efntroduceerd (bijv. een variabele)?', 'Wat is ongeveer mijn bijdrage aan dit project?', 'Wie heeft de backdoor-invoeringen gecompromitteerd en wanneer?', 'Welke low-level wijziging heeft deze functie verbroken (terwijl dat niet zo zou moeten zijn, we hebben alles gecontroleerd!?)' <\/p>\n
Versiebeheersystemen vullen dit aan met het concept van een branch \u2013 een low-level begrip dat eenvoudigweg een voortdurend fragment van de low-level projectgeschiedenis betekent, semantisch significant voor de ontwikkelaar. Branches worden doorgaans gebruikt voor specifieke implementaties van functies, soms worden meerdere branches aangemaakt voor verschillende kandidaten voor de implementatie van dezelfde functie. Door gebruik te maken van branching-workflows (die feitelijk mainstream en de standaard in ontwikkeling zijn, overal en altijd worden gebruikt), kan elke afzonderlijke ontwikkelaar effectief omgaan met veel conflicterende branches van het project, die elk verschillen in gereedheid of kwaliteit. Dit stelt ontwikkelaars in staat om de resultaten van hun werk en dat van anderen te combineren zonder telkens alles handmatig opnieuw te typen. <\/p>\n
Normaal gesproken wordt er een hoofdbranch gemaakt die het 'offici\u00eble' product vertegenwoordigt, waaruit zijbranches voor elke functie takken, die regelmatig (bij voorkeur \u2013 na elke commit) worden gesynchroniseerd met de hoofdbranch, zodat ontwikkelaars kunnen werken met de meest recente versie van het product en tegelijkertijd functies kunnen implementeren die ze momenteel ontwikkelen, waardoor problemen die voortkomen uit de acties van andere ontwikkelaars zo vroeg mogelijk worden gedetecteerd. <\/p>\n
Bij het proberen te combineren van de functies van verschillende snapshots (wat simpelweg het vinden van een gemeenschappelijke voorouder is en het toepassen van de daaruit voortvloeiende changesets, opeenvolgend boven een andere, deze operatie wordt rebase genoemd, terwijl samenvoegen bijna hetzelfde is als rebase, alleen dan structureert het de commitgrafiek anders, waardoor het ongemakkelijk wordt om ermee te werken, daarom proberen mensen samenvoegingen te vermijden ten gunste van rebases) ontstaan er problemen. Moderne versiebeheersystemen (VCS) gebruiken interne algoritmen voor het samenvoegen van wijzigingen, die simpelweg bestanden opsplitsen in afzonderlijke regels, elke regel beschouwen als een teken en bestanden als hun reeksen, en vervolgens algoritmen toepassen voor hun samenvoeging, die hun oorsprong vindt in bio-informatica. <\/p>\n
Helaas heeft deze regelmatige weergave van de broncode niets te maken met de inhoud ervan. Het enige voordeel is dat het eenvoudig en universeel is. Deze discrepantie leidt tot conflicten, wat een constante bron van hoofdpijn is voor ontwikkelaars. Het oplossen van conflicten vereist dat de ontwikkelaar beide versies van de code grondig bestudeert, niet alleen de secties die door het regelmatige vergelijkingsalgoritme zijn aangemerkt als 'gewijzigd' of 'conflictueus', maar mogelijk ook het hele project. <\/p>\n
De ontwikkelaar moet de wijzigingen begrijpen, handmatig de gecombineerde code schrijven en eventuele discrepanties oplossen. Het aantal problemen neemt toe wanneer de regelmatige tool de wijzigingen verkeerd identificeert, wat vaak voorkomt bij grote wijzigingen, inclusief triviale zoals het herformatteren van code. Als latere wijzigingen niet kunnen worden toegepast op de handmatig gecombineerde code, wordt de situatie een complete nachtmerrie. Ondanks deze angstaanjagende gevallen, werkt het regelmatige algoritme in de meeste gevallen, vooral als ontwikkelaars actief proberen geen problemen te veroorzaken. Een van de manieren om dergelijke problemen te minimaliseren is door het verplichte gebruik van canonisatie-tools, zoals black, voor de verwerking van de bronnen. <\/p>\n
Natuurlijk is de juiste oplossing voor vreselijke gevallen (en in het algemeen, niet alleen voor hen, een regel-voor-regel algoritme \u2014 dit is een heuristiek, het kan triviaal leiden tot niet-werkende code, bijvoorbeeld als een ontwikkelaar een variabele hernoemt terwijl een andere ondertussen een stuk nieuwe code schrijft dat die variabele gebruikt, er zal geen merge\/rebase-conflict zijn, maar het resultaat zal niet werken) \u2014 het gebruik van het juiste interne model. <\/p>\n
Hoewel het onderzoek op dit gebied al bijna 30 jaar gaande is en heeft geleid tot de ontwikkeling van verschillende propri\u00ebtaire commerci\u00eble producten, zijn deze onderzoeken tot onlangs niet omgezet in praktisch toepasbare producten met open source. De meeste open-source oplossingen begonnen zich in het begin van de jaren 2010 te ontwikkelen en waren vooral gericht op de programmeertaal Java. <\/p>\n
De meest opvallende vrije implementatie uit die tijd, GumTree, is ontwikkeld door een onderzoeker met een academische achtergrond, geschreven in Java, heeft zijn eigen abstracte interne representatie, voorafgaand aan treesitter, en heeft back-ends die zowel gebaseerd zijn op treesitter als op andere tools voor het parseren van broncode naar abstracte representaties. Dit systeem kan alleen genereren (in de vorm van een tekstlog van gebeurtenissen, er is ook een API die triviaal kan worden aangeroepen vanuit elke programmeertaal met bindings naar Java) en visualiseren van wijzigingen. Echter, voor het samenvoegen van wijzigingen, alsook voor het bekijken van de door het systeem gegenereerde diff-bestanden, is het uit de doos niet toepasbaar (hoewel het waarschijnlijk is dat het uploaden van diffs via de API kan worden gerealiseerd). <\/p>\n
Een jongere en meer praktisch toepasbare implementatie van difftastic is geschreven in Rust, gebaseerd op treesitter, en is gericht op het genereren van gemarkeerde diffs in de console. Dit systeem is ook gericht op het visualiseren van diffs en heeft absoluut niet als doel wijzigingen samen te voegen of patches toe te passen. <\/p>\n
Onlangs is het project mergiraf verschenen en is het actief in ontwikkeling. Dit hulpmiddel, geschreven in Rust (neemt 21 MiB in beslag!), is ook gebaseerd op treesitter, dat al een standaard is geworden voor parsers van contextvrije grammatica's in ontwikkelingshulpmiddelen, net zoals LLVM dat is geworden voor optimalisering van laag-niveau instructievoorstellingen. In tegenstelling tot concurrenten biedt mergiraf functies niet voor het genereren van diff's, maar voor automatische conflictoplossing tijdens merges. Onder de motorkap gebruikt mergiraf voor het genereren van patches een implementatie van het algoritme dat in GumTree wordt gebruikt, en voor de toepassing \u2014 een implementatie van het algoritme dat in spork wordt gebruikt, aangepast voor treesitter-structuren. <\/p>\n
Helaas is de serialisatie van patches naar bestanden die later kunnen worden toegepast niet gerealiseerd (maar het is heel goed mogelijk dat dit kan worden gerealiseerd door het parseren van de logboeken van gebeurtenissen die door GumTree worden gegenereerd). Een andere veelbelovende manier om verschillen toe te passen, kan zijn door deze niet via patches toe te passen, maar via de refactoring-functionaliteit van LSP-servers, wat kan helpen bij het detecteren van conflicten op projectniveau. Visualisatie wordt alleen ondersteund voor conflicten. <\/p>\n
Voorbeeld van werking: algemene voorouder \u2018base.py\u2019 (tabs als inspringing, extra regel aan het begin) foo = 1 def main(): print(foo + 2 + 3) \u2018a.py\u2019 (tabs blijven inspringing, 2 extra regels aan het begin in plaats van \u00e9\u00e9n, voor debug printing wordt de bibliotheek icecream gebruikt, klasse \u2018baz\u2019 is toegevoegd: from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): \u2018>>>baz>>>\u2019 \u2018b.py\u2019 (de variabele \u2018foo\u2019 is hernoemd naar \u2018bar\u2019, verwerkt met \u2018black\u2019 na wijzigingen, resulterend in inspringingen \u2014 ruimtes en extra regels zijn verwijderd): bar = 1 def main(): print(bar + 2 + 3) Aanroep .\\\/mergiraf merge .\\\/base.py .\\\/a.py .\\\/b.py -x a.py -y b.py -s base.py -o .\\\/res.py geeft de volgende uitkomst: from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): \u2018>>>baz>>>\u2019 (voor debug printing is de bibliotheek \u2018icecream\u2019 gebruikt, de variabele \u2018foo\u2019 is hernoemd naar \u2018bar\u2019, verwerkt met \u2018black\u2019 na wijzigingen, resulterend in inspringingen \u2014 ruimtes en extra regels zijn verwijderd, mengeling van tabs en ruimtes voor inspringing, maar de toegestane vorm). <\/p>\n