Discussione matematica: teorema sul sistema di controllo di revisione git?

Vorrei tenere un discorso di matematica sul sistema di controllo di revisione git . Ora è ampiamente usato in matematica e nell'industria dell'informatica. Ad esempio, la comunità HoTT (Homotopy Type Theory) lo utilizza ed è il sistema ideale per la modifica collaborativa di file di testo, siano essi codice sorgente o markup in lattice.

So che git usa la nozione di un grafico aciclico diretto, che è un inizio. Tuttavia, un buon discorso di matematica menziona prove e teoremi.

Quale teorema potrei dimostrare su Git che è effettivamente rilevante per il suo uso?

Un repository git può essere pensato come un insieme di revisioni parzialmente ordinato (in cui una revisione è precedente a un'altra nell'ordine se è un successore diretto o indiretto di quella precedente). Gli ordini parziali che si ottengono dai repository git tendono ad avere una larghezza ridotta (la dimensione dell'insieme più ampio di revisioni reciprocamente indipendenti) poiché la larghezza è direttamente correlata al numero di sviluppatori attivi e al numero di forcelle diverse su cui potrebbe funzionare un singolo sviluppatore su.

Sulla base di questo contesto, suggerirei il teorema di Dilworth , secondo il quale la larghezza di qualsiasi ordine parziale è uguale al numero minimo di catene (sottoinsiemi totalmente ordinati) necessari per coprire tutte le versioni. E per renderlo in tema per questa scheda, potresti anche menzionare gli algoritmi basati sulla corrispondenza dei grafici per calcolare la larghezza e trovare una copertura di un numero minimo di catene in tempo polinomiale.

Un modo in cui ciò potrebbe essere rilevante per l'uso effettivo in Git è in un sistema per visualizzare la cronologia delle versioni di un sistema: la maggior parte dei sistemi di visualizzazione Git che ho visto disegnare tempo sull'asse verticale e versioni indipendenti del repository in orizzontale, quindi questo ti darebbe un modo per organizzare la visualizzazione in un piccolo numero di tracce verticali indipendenti.

In alternativa, se si desidera qualcosa di più ambizioso e avanzato, provare la struttura dei dati dell'albero della colpa di Demaine et al. , Che è direttamente motivata dalla risoluzione dei conflitti nei sistemi di controllo delle versioni simili a git.

È interessante notare che c'è una nascente matematizzazione dei sistemi di controllo delle versioni, sebbene a questo punto sia applicabile solo parzialmente a Git. Si chiama teoria delle patch [1, 2, 3, 4, 5] ed è nata nel contesto del sistema di controllo della versione DARCS. Può essere visto come una teoria astratta di ramificazione e fusione . Recentemente alla teoria delle patch sono stati dati trattamenti HoTT [6] e categorici [7].

La teoria delle patch è in fase di elaborazione e non copre tutti gli aspetti del controllo della versione, ma contiene molti teoremi che è possibile esaminare. È un chiaro esempio di teoria applicabile al "mondo reale" - non sorprende, poiché la teoria delle patch è un'astrazione / semplificazione di qualcosa di molto concreto. Allo stesso tempo si connette con matematica all'avanguardia come HoTT.

1. J. Dagit, Modifiche di tipo corretto - Un approccio sicuro all'implementazione del controllo versione .
2. G. Sittampalam, Alcune proprietà della teoria delle patch di Darcs .
3. I. Lynagh, teoria del percorso del campo.
4. D. Roundy, implementando il formalismo di patch darc ... e verificandolo.
5. J. Jacobson, una formalizzazione della teoria delle patch di Darcs utilizzando semigruppi inversi .
6. C. Angiuli, E. Morehouse, DR Licata, R. Harper, Teoria della patch omotopica .
7. S. Mimram, C. Di Giusto, Una teoria categorica delle patch .

Un'altra alternativa è quella di esaminare strutture di dati persistenti (o puramente funzionali). La struttura dei dati interna di Git può essere vista come un albero persistentemente confluente :

una struttura di dati persistente è una struttura di dati che conserva sempre la versione precedente di se stessa quando viene modificata. Tali strutture di dati sono effettivamente immutabili, poiché le loro operazioni non aggiornano (visibilmente) la struttura sul posto, ma producono sempre una nuova struttura aggiornata.

Una struttura di dati è parzialmente persistente se è possibile accedere a tutte le versioni ma è possibile modificare solo la versione più recente. La struttura dei dati è completamente persistente se è possibile accedere e modificare entrambe le versioni. Se esiste anche un'operazione di fusione o unione che può creare una nuova versione da due versioni precedenti, la struttura dei dati viene chiamata confluentemente persistente.

Anche questa domanda è rilevante.

Sì, puoi definire matematicamente come funziona Git. Potresti definire strutture Git primitive e operazioni Git su di esse e quindi avere teoremi che dimostrano che l'uso di queste operazioni in determinati modi raggiunge determinati obiettivi di livello superiore, o tenta di caratterizzare o quantificare situazioni in cui non è così. (Ad esempio, la dipendenza di Git dagli hash lascia un piccolo margine di errore.)

Un'altra idea è fare la stessa cosa per Subversion, quindi produrre teoremi che confrontino i due. Ad esempio, si afferma spesso che Git è meglio nel gestire le fusioni; puoi avere teoremi che lo dimostrano, qualitativamente o quantitativamente.

L'utilità dipenderebbe in modo critico dal fare le giuste astrazioni. Descrivere matematicamente il funzionamento del codice sorgente Git in tutti i dettagli è inutile: il codice sorgente stesso lo fa in modo molto più efficace e conciso.