Ok, j'ai lu les articles du blog de Joe Neeman et de ce que j'ai compris: non, il n'y a pas de magie dans pijul, les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
Par contre, si je comprends bien, pijul devrait résoudre plus souvent les conflits automatiquement, grâce à la théorie des patchs mathématiques (au contrario de git qui fait de l'heuristique).
Dans son blog, Joe Neeman définit un patch mathématique comme ce ci:
Le patch dépend d'un fichier source
Le patch travaille ligne par ligne (et non pas mot par mot)
Un patch peut ajouter des lignes, mais ne pas les modifier
Pour le dernier point, ça paraît bizarre, mais c'est résolu dans pijul avec l'ajout d'un attribut "fantôme" à une ligne pour la marquer comme supprimée bien qu'elle reste dans la représentation de pijul.
Ensuite, il explique que ce framework mathématiques a besoin de simplifier la définition d'un fichier: un fichier n'est plus une simple liste ordrée de lignes, mais devient un graphe ordré de lignes. Cette simplification de la représentation d'un fichier permet à deux lignes différentes d'avoir la même ligne parente.
Cette représentation de fichier sous forme de graphe de lignes est appelée graggle (mot valise entre graphe et ligne) pour simplifier. Bien sûr, un graggle est inutilisable par un compilateur / un éditeur de texte si deux lignes ont le même parent.
Ce qui est intéressant, c'est que maintenant, pijul a beaucoup plus d'informations pour résoudre les conflits, car il ne va plus traiter les fichiers lignes par lignes, mais il va comparer des graphes mathématiques qui contiennent plus d'information, car chaque ligne a un parent et un enfant (alors qu'avec la liste on ne considérait que la position de la ligne dans la liste).
Enfin, la procédure de fusion est finalement celle-ci: en partant d'un fichier O (pour original), nous avons deux patchs p et q qui créent les versions A et B du fichier. Pour créer les patch r et s qui fusionnent respectivement depuis A et depuis B dans une nouvelle version commune du fichier nommée M (pour merged):
Ecrire les graggles de A et B l'un à côté de l'autre
Quand une ligne de A et de B partagent le même parent, fusionnez les parents en une seule ligne.
A la fin de cette procédure, pijul se retrouve avec un nouveau graggle M qui est cohérent dans sa représentation interne des fichiers. Par contre, cette version est impossible à utiliser pour nos outils qui s'attendent à avoir un fichier représenté sous une série ordrée de ligne (et non pas un graphe).
Il y a donc un conflit que l'utilisateur devra gérer en créant un nous patch t qui va transformer le graggle M en graggle F (pour flattened) qui aplatit à nouveau le graphe en une liste de ligne.
Le premier article amène très bien ces idées avec de bonnes illustrations, je vous conseille de les lire si vous voulez avoir une meilleure vision de ce qui se passe.
J'ai le sentiment que grâce à cette théorie pijul pourra résoudre plus souvent automatiquement les conflits, car il enregistre plus d'informations dans ses patchs (il travaille avec des graggles comme fichier source pour les patch).
En plus, dans les articles suivant, Joe Neeman montre la puissance de pijul avec un exemple assez simple: essayer de faire un patch qui annule un ancien patch, mais ceci après un merge dans l'historique. Dans ce cas, git perd les pédales et va demander à l'utilisateur de résoudre à nouveau un conflit. Alors que pijul saura bien se tirer d'affaire car, dans sa représentation interne, il n'y a jamais eu de conflit, il n'a eu qu'une simple série de patch (bien qu'en pratique l'utilisateur à du faire un patch supplémentaire pour aplatir le graphe).
Comme il a une série cohérente de patch et avec beaucoup d'informations (les graggles au lieu des fichiers), pijul peut s'en sortir très facilement de cette situation.
Un autre exemple qui est donné est la fonction cherry-pick de git: avec git, quand on veut récupérer un commit d'une branche à une autre, on se retrouve toujours avec des commits différents (leur hash est différent, et comme git ne travaille pas avec le contenu des commits, il ne sait pas que le contenu est identique). Le jour où on veut fusionner une branche qui a fait du cherry-pick sur une autre, git demande à nouveau de fusionner les fichiers (car il ne voit pas que c'était le même commit). Pijul s'en sort très bien dans ce cas, simplement parce qu'il travaille avec le contenu des graggles qui ont bien plus d'informations que des fichiers plats.
Finalement, j'espère qu'à terme pijul trouvera sa voie et fera beaucoup d'adepte comme git à l'époque où le marché était dominé par CVS et SVN. Il y a encore beaucoup de boulot, mais je pense sincèrement que Pierre-Étienne Meunier est sur la bonne voie avec cette innovation technologique (et ce surtout quand on se lance sur de nouveaux projets qui vont nécessiter du maintient de code à long terme).
... mais quand même tous les algos qui marchent, pour la première fois !
Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
Bravo !
Il y a maintenant besoin de former une communauté qui se mette à travailler sur des articles de vulgarisation, des exemples, d'intégrer pijul a des forges logicielles...
PS: tous ces propos ne sont que mon point de vue formé sur les explications de Joe Neeman, un mathématicien externe au projet pijul qui analyse ces idées.
[^] # Re: Exemples concrets?
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
Ok, j'ai lu les articles du blog de Joe Neeman et de ce que j'ai compris: non, il n'y a pas de magie dans pijul, les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.
Par contre, si je comprends bien, pijul devrait résoudre plus souvent les conflits automatiquement, grâce à la théorie des patchs mathématiques (au contrario de git qui fait de l'heuristique).
Dans son blog, Joe Neeman définit un patch mathématique comme ce ci:
Pour le dernier point, ça paraît bizarre, mais c'est résolu dans pijul avec l'ajout d'un attribut "fantôme" à une ligne pour la marquer comme supprimée bien qu'elle reste dans la représentation de pijul.
Ensuite, il explique que ce framework mathématiques a besoin de simplifier la définition d'un fichier: un fichier n'est plus une simple liste ordrée de lignes, mais devient un graphe ordré de lignes. Cette simplification de la représentation d'un fichier permet à deux lignes différentes d'avoir la même ligne parente.
Cette représentation de fichier sous forme de graphe de lignes est appelée graggle (mot valise entre graphe et ligne) pour simplifier. Bien sûr, un graggle est inutilisable par un compilateur / un éditeur de texte si deux lignes ont le même parent.
Ce qui est intéressant, c'est que maintenant, pijul a beaucoup plus d'informations pour résoudre les conflits, car il ne va plus traiter les fichiers lignes par lignes, mais il va comparer des graphes mathématiques qui contiennent plus d'information, car chaque ligne a un parent et un enfant (alors qu'avec la liste on ne considérait que la position de la ligne dans la liste).
Enfin, la procédure de fusion est finalement celle-ci: en partant d'un fichier O (pour original), nous avons deux patchs p et q qui créent les versions A et B du fichier. Pour créer les patch r et s qui fusionnent respectivement depuis A et depuis B dans une nouvelle version commune du fichier nommée M (pour merged):
A la fin de cette procédure, pijul se retrouve avec un nouveau graggle M qui est cohérent dans sa représentation interne des fichiers. Par contre, cette version est impossible à utiliser pour nos outils qui s'attendent à avoir un fichier représenté sous une série ordrée de ligne (et non pas un graphe).
Il y a donc un conflit que l'utilisateur devra gérer en créant un nous patch t qui va transformer le graggle M en graggle F (pour flattened) qui aplatit à nouveau le graphe en une liste de ligne.
Le premier article amène très bien ces idées avec de bonnes illustrations, je vous conseille de les lire si vous voulez avoir une meilleure vision de ce qui se passe.
J'ai le sentiment que grâce à cette théorie pijul pourra résoudre plus souvent automatiquement les conflits, car il enregistre plus d'informations dans ses patchs (il travaille avec des graggles comme fichier source pour les patch).
En plus, dans les articles suivant, Joe Neeman montre la puissance de pijul avec un exemple assez simple: essayer de faire un patch qui annule un ancien patch, mais ceci après un merge dans l'historique. Dans ce cas, git perd les pédales et va demander à l'utilisateur de résoudre à nouveau un conflit. Alors que pijul saura bien se tirer d'affaire car, dans sa représentation interne, il n'y a jamais eu de conflit, il n'a eu qu'une simple série de patch (bien qu'en pratique l'utilisateur à du faire un patch supplémentaire pour aplatir le graphe).
Comme il a une série cohérente de patch et avec beaucoup d'informations (les graggles au lieu des fichiers), pijul peut s'en sortir très facilement de cette situation.
Un autre exemple qui est donné est la fonction cherry-pick de git: avec git, quand on veut récupérer un commit d'une branche à une autre, on se retrouve toujours avec des commits différents (leur hash est différent, et comme git ne travaille pas avec le contenu des commits, il ne sait pas que le contenu est identique). Le jour où on veut fusionner une branche qui a fait du cherry-pick sur une autre, git demande à nouveau de fusionner les fichiers (car il ne voit pas que c'était le même commit). Pijul s'en sort très bien dans ce cas, simplement parce qu'il travaille avec le contenu des graggles qui ont bien plus d'informations que des fichiers plats.
Finalement, j'espère qu'à terme pijul trouvera sa voie et fera beaucoup d'adepte comme git à l'époque où le marché était dominé par CVS et SVN. Il y a encore beaucoup de boulot, mais je pense sincèrement que Pierre-Étienne Meunier est sur la bonne voie avec cette innovation technologique (et ce surtout quand on se lance sur de nouveaux projets qui vont nécessiter du maintient de code à long terme).
Il a écrit dans un commentaire plus bas:
Et si j'ai bien compris, c'est la fête, parce que l'implémentation a réussi et la théorie tient la route :)
Bravo !
Il y a maintenant besoin de former une communauté qui se mette à travailler sur des articles de vulgarisation, des exemples, d'intégrer pijul a des forges logicielles...
PS: tous ces propos ne sont que mon point de vue formé sur les explications de Joe Neeman, un mathématicien externe au projet pijul qui analyse ces idées.