Discussion mathématique: Théorème sur le système de contrôle de révision git?

Je voudrais donner une conférence mathématique sur le système de contrôle de révision git . Il est maintenant largement utilisé en mathématiques ainsi que dans l'industrie informatique. Par exemple, la communauté HoTT (Homotopy Type Theory) l'utilise, et c'est le système de référence pour l'édition collaborative de fichiers texte, qu'il s'agisse de code source ou de balisage en latex.

Je sais que git utilise la notion de graphe acyclique dirigé, qui est un début. Cependant, un bon exposé sur les mathématiques mentionne des preuves et des théorèmes.

Quel théorème pourrais-je prouver à propos de git qui est réellement pertinent pour son utilisation?

Un référentiel git peut être considéré comme un ensemble de révisions partiellement ordonné (où une révision est antérieure à une autre dans l'ordre s'il s'agit d'un successeur direct ou indirect de la précédente). Les commandes partielles que vous recevez des référentiels git ont tendance à avoir une faible largeur (la taille du plus grand ensemble de révisions indépendantes les unes des autres) car la largeur est directement liée au nombre de développeurs actifs et au nombre de fourches différentes qu'un développeur individuel pourrait travailler sur.

Sur la base de ce contexte, je suggérerais le théorème de Dilworth , qui stipule que la largeur de tout ordre partiel est égale au nombre minimum de chaînes (sous-ensembles totalement ordonnés) nécessaires pour couvrir toutes les versions. Et pour le rendre sur le sujet pour cette carte, vous pouvez également mentionner les algorithmes basés sur la correspondance de graphe pour calculer la largeur et trouver une couverture par un nombre minimum de chaînes en temps polynomial.

Une façon dont cela pourrait être pertinent pour une utilisation réelle dans Git est dans un système pour visualiser l'historique des versions d'un système: la plupart des systèmes de visualisation Git que j'ai vus dessiner le temps sur l'axe vertical et les versions indépendantes du référentiel horizontalement, donc ce vous donnerait un moyen d'organiser la visualisation en un petit nombre de pistes verticales indépendantes.

Alternativement, si vous voulez quelque chose de plus ambitieux et avancé, essayez la structure de données de l'arbre de blâme de Demaine et al., Qui est directement motivée par la résolution des conflits dans les systèmes de contrôle de version de type git.

Fait intéressant, il existe une mathématisation naissante des systèmes de contrôle de version, bien qu'à ce stade, elle ne soit que partiellement applicable à Git. Cela s'appelle la théorie des patchs [1, 2, 3, 4, 5] et est apparue dans le contexte du système de contrôle de version DARCS. Elle peut être considérée comme une théorie abstraite de la ramification et de la fusion . Récemment, la théorie des patchs a reçu des traitements HoTT [6] et catégoriques [7].

La théorie des correctifs est en cours d'élaboration et ne couvre pas tous les aspects du contrôle de version, mais contient de nombreux théorèmes que vous pourriez examiner. C'est un exemple clair de théorie applicable au `` monde réel '' - pas surprenant, car la théorie des patchs est une abstraction / simplification de quelque chose de très concret. En même temps, il se connecte à des mathématiques de pointe comme HoTT.

1. J. Dagit, Modifications de type correct - Une approche sûre pour la mise en œuvre du contrôle de version .
2. G. Sittampalam, Quelques propriétés de la théorie des patchs darcs .
3. I. Lynagh, Camp Path Theory.
4. D. Roundy, implémenter le formalisme du patch darcs ... et le vérifier.
5. J. Jacobson, Une formalisation de la théorie des patchs Darcs utilisant des semi-groupes inverses .
6. C. Angiuli, E. Morehouse, DR Licata, R. Harper, Homotopical Patch Theory .
7. S. Mimram, C. Di Giusto, Une théorie catégorique des correctifs .

Une autre alternative consiste à examiner les structures de données persistantes (ou purement fonctionnelles). La structure de données interne de Git peut être considérée comme un arbre persistant convergent :

une structure de données persistante est une structure de données qui conserve toujours la version précédente d'elle-même lorsqu'elle est modifiée. De telles structures de données sont effectivement immuables, car leurs opérations ne mettent pas (visiblement) à jour la structure en place, mais produisent toujours une nouvelle structure mise à jour.

Une structure de données est partiellement persistante si toutes les versions sont accessibles mais que seule la version la plus récente peut être modifiée. La structure des données est entièrement persistante si chaque version peut être à la fois consultée et modifiée. S'il existe également une opération de fusion ou de fusion qui peut créer une nouvelle version à partir de deux versions précédentes, la structure de données est appelée convergente persistante.

Cette question est également pertinente.

Oui, vous pouvez définir mathématiquement le fonctionnement de Git. Vous pouvez définir des structures Git primitives et des opérations Git sur celles-ci, puis disposer de théorèmes prouvant que l'utilisation de ces opérations de manière particulière permet d'atteindre des objectifs de niveau supérieur particuliers, ou tenter de caractériser ou de quantifier des situations dans lesquelles ce n'est pas le cas. (Par exemple, la dépendance de Git sur les hachages laisse une toute petite marge d'erreur.)

Une autre idée est de faire la même chose pour Subversion, puis de produire des théorèmes qui comparent les deux. Par exemple, on prétend souvent que Git est mieux à même de gérer les fusions; vous pouvez avoir des théorèmes qui le prouvent, qualitativement ou quantitativement.

L'utilité dépendrait de manière critique de faire les bonnes abstractions. Décrire mathématiquement le fonctionnement du code source de Git dans tous ses détails est inutile: le code source lui-même le fait de manière beaucoup plus efficace et concise.