\u00c8 stato rilasciato il progetto mergiraf 0.4, che sviluppa un driver per Git con implementazione della funzionalit\u00e0 di merge a tre vie. Mergiraf supporta la risoluzione di vari tipi di conflitti durante il merge e pu\u00f2 essere utilizzato per diversi linguaggi di programmazione e formati di file. \u00c8 possibile utilizzare mergiraf come richiamo separato per gestire i conflitti che sorgono nell'uso di Git standard, nonch\u00e9 sostituirlo in Git come gestore di merge per ampliare le funzionalit\u00e0 di comandi come merge, revert, rebase e cherry-pick. Il codice \u00e8 distribuito sotto licenza GPLv3. Nella nuova versione \u00e8 stata aggiunta la supporto per i linguaggi Python, TOML, Scala e Typescript, e sono state effettuate ottimizzazioni delle prestazioni. <\/p>\n
Di seguito \u00e8 fornita una descrizione dettagliata dei problemi risolti con mergiraf: <\/p>\n
Il software \u00e8 un esempio eccellente di un sistema estremamente complesso. I sistemi complessi hanno una caratteristica comune: sono COMPLESSI e non ci si pu\u00f2 aspettare che un comportamento complesso emerga da solo, casualmente. Al contrario, questi sistemi evolvono nel tempo, passo dopo passo, e ogni mutazione viene accuratamente verificata a ciascun passaggio. Per raggiungere ci\u00f2, \u00e8 necessaria una struttura ben definita e gli strumenti appropriati. L'evoluzione di qualsiasi sistema complesso pu\u00f2 essere visualizzata come un albero orientato, dove la radice rappresenta un insieme vuoto di funzioni e ogni nodo, eccetto la radice, \u00e8 il risultato dell'applicazione di una mutazione al suo genitore. <\/p>\n
Nel contesto dei prodotti, ogni nodo \u00e8 chiamato \"versione\", rappresentando un insieme specifico di funzioni e antifunzioni. Qualsiasi modifica a questo insieme \u00e8 considerata una mutazione, che forma un arco nel nostro grafo orientato e aciclico. Queste funzioni sono per loro natura astratte; non riflettono direttamente i modi in cui funzionano i sistemi fisici, ma piuttosto dimostrano come agenti razionali percepiscono l'utilit\u00e0 di questi sistemi. Per tradurre le idee in attuazioni reali nel mondo, \u00e8 necessario rimboccarsi le maniche e immergersi nei dettagli *abbastanza* a basso livello, nel linguaggio attraverso il quale si pu\u00f2 esprimere e spiegare come tutto funzioni concretamente. Nello sviluppo software, questi bassi livelli sono generalmente rappresentati dal codice sorgente. <\/p>\n
Per portare gradualmente il codice sorgente in uno stato che manifesti il comportamento richiesto e documentare come ci siano arrivati, i programmatori presentano il loro lavoro in termini di snapshot e changeset. Uno snapshot rappresenta uno stato specifico del prodotto con tutti i dettagli di basso livello, mentre un changeset indica la transizione tra gli snapshot. Di solito, gli snapshot sono generati da singoli changeset ai loro genitori, quindi questi snapshot vengono quasi sempre etichettati con ci\u00f2 che i changeset hanno creato, ed \u00e8 per questo che questi termini vengono spesso usati in modo intercambiabile. <\/p>\n
A volte esistono snapshot ottenuti a seguito di diversi passaggi \u2014 fusioni di commit. Sono difficili da gestire, pertanto di solito si evita di usarli. I moderni sistemi di controllo versione open source, come Git, offrono capacit\u00e0 di base per gestire i flussi di lavoro di sviluppo. Consentono agli sviluppatori di organizzare snapshot in grafi orientati e aciclici, annotarli con commenti e, se necessario, cambiarne l'ordine. <\/p>\n
Questa funzionalit\u00e0 consente agli sviluppatori di scrivere una storia semantica del progetto, fondamentale per il debug e per rispondere a domande come: \"Perch\u00e9 \u00e8 stato introdotto questo dettaglio a basso livello (ad es., una variabile)?\", \"Qual \u00e8 stata approssimativamente la mia percentuale di contributo a questo progetto?\", \"Chi ha compromesso gli exploit e quando?\", \"Quale modifica a basso livello ha rotto questa funzione (anche se non dovrebbe, abbiamo controllato tutto!?)\". <\/p>\n
I sistemi di controllo versione completano questo concetto con quello di ramo \u2014 un concetto a basso livello che significa semplicemente un frammento continuo della storia a basso livello del progetto, semanticamente significativo per lo sviluppatore. I rami sono generalmente utilizzati per implementazioni specifiche di funzionalit\u00e0, e a volte vengono creati diversi rami per diversi candidati all'implementazione della stessa funzionalit\u00e0. Utilizzando flussi di lavoro con ramificazioni (che sono di fatto lo standard e la prassi di sviluppo, utilizzati ovunque), ogni singolo sviluppatore pu\u00f2 gestire in modo efficace molti rami conflittuali del progetto, ognuno dei quali varia in termini di prontezza o qualit\u00e0. Questo consente agli sviluppatori di combinare i risultati del proprio lavoro e di altri senza dover reinserire manualmente tutto ogni volta. <\/p>\n
Di solito si crea un ramo principale, rappresentante il prodotto \"ufficiale\", da cui si ramificano rami secondari per ogni funzione, che si sincronizzano regolarmente (ideale dopo ogni commit) con il ramo principale, permettendo agli sviluppatori di lavorare con la versione pi\u00f9 recente del prodotto e contemporaneamente implementare le funzionalit\u00e0 che stanno attualmente sviluppando, rilevando problemi derivanti dalle azioni di altri sviluppatori il prima possibile. <\/p>\n
Quando si cerca di combinare funzionalit\u00e0 di vari snapshot (che \u00e8 semplicemente trovare un antenato comune e applicare i changeset che li generano successivamente sopra l'altro, questa operazione \u00e8 chiamata rebase; la fusione, d'altra parte, \u00e8 quasi come un rebase, ma struttura il grafo dei commit in modo diverso, rendendolo scomodo da manipolare, quindi si tende a evitare le fusioni a favore dei rebase), sorgono problemi. I moderni sistemi di controllo versione (VCS) utilizzano algoritmi interni di fusione delle modifiche, che semplicemente suddividono i file in singole linee, trattano ogni linea come un simbolo e i file come le loro sequenze, applicando quindi algoritmi per la loro fusione, che provengono dalla bioinformatica. <\/p>\n
Sfortunatamente, una rappresentazione riga per riga del codice sorgente non ha nulla a che fare con il suo contenuto. L'unico suo pregio \u00e8 che \u00e8 semplice e universale. La discrepanza porta a conflitti, risultando in una costante fonte di mal di testa per gli sviluppatori. Risolvere i conflitti richiede che lo sviluppatore esamini attentamente entrambe le versioni del codice, non solo le sezioni contrassegnate dall'algoritmo di confronto come \"modificate\" o \"in conflitto\", ma forse anche l'intero progetto. <\/p>\n
Lo sviluppatore deve comprendere le modifiche, scrivere manualmente il codice di unione e risolvere eventuali discrepanze. I problemi aumentano quando lo strumento riga per riga identifica erroneamente le modifiche, il che accade frequentemente durante grandi cambiamenti, comprese le modifiche banali come il riformattazione del codice. Se i successivi cambiamenti non possono essere applicati al codice unito manualmente, la situazione diventa un incubo totale. Nonostante questi casi allarmanti, nella maggior parte dei casi l'algoritmo riga per riga funziona, soprattutto se gli sviluppatori si impegnano attivamente a non creargli problemi. Uno dei modi per ridurre al minimo tali problemi \u00e8 l'obbligo di elaborare le sorgenti tramite strumenti di canonicalizzazione, come black. <\/p>\n
\u00c8 evidente che la soluzione corretta per i casi allarmanti (e non solo per quelli, poich\u00e9 l'algoritmo riga per riga \u00e8 un'euristica, e pu\u00f2 in modo banale portare a codice non funzionante, ad esempio se un sviluppatore rinomina una variabile mentre un altro sta scrivendo un nuovo pezzo di codice che utilizza quella variabile, non ci sar\u00e0 conflitto di unione\/ribase, ma il risultato diventer\u00e0 non funzionante) \u00e8 l'uso di un modello interno corretto. <\/p>\n
Nonostante siano in corso ricerche in questo campo da circa 30 anni, che hanno portato alla creazione di diversi prodotti commerciali proprietari, fino a tempi recenti queste ricerche non erano ancora state trasformate in prodotti praticamente applicabili con codice sorgente aperto. La maggior parte delle soluzioni open source ha iniziato a svilupparsi all'inizio degli anni 2010 ed \u00e8 stata principalmente focalizzata sul linguaggio Java. <\/p>\n
La realizzazione open source pi\u00f9 notevole di quel periodo, GumTree, \u00e8 stata creata da un ricercatore con una formazione accademica, \u00e8 scritta in Java e ha una sua rappresentazione interna astratta, precedente a treesitter. Ha backend sia basati su treesitter che su altri strumenti per il parsing del codice sorgente in rappresentazioni astratte. Questo sistema \u00e8 in grado di generare (sotto forma di log testuale degli eventi, \u00e8 disponibile anche un'API che pu\u00f2 essere facilmente richiamata da qualsiasi linguaggio di programmazione che abbia binding per Java) e visualizzare le modifiche. Tuttavia, per unire le modifiche e per visualizzare i file diff generati, non \u00e8 applicabile di default (tuttavia, \u00e8 probabile che il caricamento dei diff possa essere implementato tramite API). <\/p>\n
Una realizzazione pi\u00f9 giovane e praticabile di difftastic \u00e8 scritta in Rust, \u00e8 basata su treesitter e si concentra sulla generazione di diff evidenziati nella console. Questo sistema \u00e8 anche orientato alla visualizzazione dei diff e non ha come obiettivo la fusione delle modifiche o l'applicazione di patch. <\/p>\n
Di recente \u00e8 emerso e si sta sviluppando attivamente il progetto mergiraf. Questo strumento scritto in Rust (occupa 21 MiB!) \u00e8 anche basato su treesitter, che \u00e8 gi\u00e0 diventato uno standard per i parser di grammatiche libere nel contesto degli strumenti di sviluppo, proprio come LLVM lo \u00e8 per l'ottimizzazione delle rappresentazioni di basso livello delle istruzioni. A differenza dei concorrenti, mergiraf offre funzionalit\u00e0 non per generare diff, ma per risolvere automaticamente i conflitti di unione. Sotto il cofano, mergiraf utilizza per la generazione di patch un'implementazione dell'algoritmo usato in GumTree, e per l'applicazione - un'implementazione dell'algoritmo usato in spork, adattato per le strutture treesitter. <\/p>\n
La serializzazione delle patch in file che possono essere applicati successivamente non \u00e8 attualmente implementata (ma \u00e8 molto probabile che possa essere realizzata attraverso il parsing dei log eventi generati da GumTree). Un altro modo promettente per applicare le differenze potrebbe essere l'uso delle differenze non tramite patch, ma attraverso la funzionalit\u00e0 di refactoring dei server LSP, il che potrebbe aiutare nella rilevazione dei conflitti a livello di progetto. La visualizzazione \u00e8 supportata solo per i conflitti. <\/p>\n
Esempio di funzionamento: un antenato comune \"base.py\" (righe con tabulazioni, riga vuota all'inizio) foo = 1 def main(): print(foo + 2 + 3) \"a.py\" (righe con tabulazioni, 2 righe vuote all'inizio invece di una, per la stampa di debug si utilizza la libreria icecream, \u00e8 stata aggiunta la classe \"baz\": from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): \"\"\"baz\"\"\" \"b.py\" (la variabile \"foo\" \u00e8 stata rinominata in \"bar\", elaborata con \"black\" dopo le modifiche, risultando in righe con spazi bianchi e righe vuote rimosse): bar = 1 def main(): print(bar + 2 + 3) La chiamata .\/mergiraf merge .\/base.py .\/a.py .\/b.py -x a.py -y b.py -s base.py -o .\/res.py d\u00e0 il seguente risultato from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): \"\"\"baz\"\"\" (per la stampa di debug si utilizza la libreria \"icecream\", la variabile \"foo\" \u00e8 stata rinominata in \"bar\", elaborata con \"black\" dopo le modifiche, risultando in righe con spazi e righe vuote rimosse, un misto di tabulazioni e spazi per l'indentazione, ma nel formato autorizzato). <\/p>\n