pmeunier a écrit 108 commentaires

Non, c'est justement un exemple où Git ne marche pas, mais Pijul oui.

Par contre, vous avez conscience que Git est hégémonique aujourd'hui ? Quasiment toutes les forges s'appuient dessus. Un écosystème phénoménal s'est construit autour pour pallier certaines de ses erreurs de jeunesse, …

C'est vrai, et on en avait totalement conscience au moment de démarrer. Mais:

• Au début, comme Florent et moi travaillons en général sur des modèles de calcul asynchrone (plutôt sur de la vraie théorie), le défi nous a motivés.
• Ensuite, on a vu à la première démo (même toute ridicule) que c'était un sujet controversé, que l'hégémonie de Git ne faisait pas que des heureux, que des gens souffraient en l'utilisant.
• Et on a parlé avec des gens qui n'utiliseront jamais Git, même s'ils ont besoin d'un VCS, parce qu'ils ont besoin d'un outil aussi puissant que Git, mais beaucoup plus facile à utiliser (ce n'est pas pour du code).

L'autre point qui ne manquait jamais d'apparaître dans les trolls de l'âge d'or des VCS, c'était quand même les perfs assez déplorables de Darcs.

C'est ça qui a tué Darcs. Le principal utilisateur était GHC (le compilateur Haskell), avec un dépot énorme, et le merge exponentiel, l'incapacité à gérer des gros fichiers ou des gros patchs ont poussé GHC à changer, même s'ils ont essayé de le soutenir pendant longtemps. À l'époque où Haskell était encore confidentiel, Darcs a été le seul projet open source écrit avec, en dehors du compilateur.

Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.

Pas du tout. Notre merge est toujours en temps O(log H), où H est le nombre de lignes écrites depuis le début du dépot, il n'y a pas d'heuristique, il est complètement déterministe, donc il n'y a pas d'optimum local, puisqu'il n'y a rien à minimiser (contrairement à diff3).

Ceci ne remet-il pas en question tout l'édifice ?

Donc non !

Pourrais-tu développer un peu ?

En fait c'est ultra simple. Pijul modélise un fichier comme un graphe de lignes. Faire un patch, c'est ajouter des sommets et des arêtes, ou changer les étiquettes des arêtes. Fusionner deux patchs, c'est faire l'union de tous ces changements, c'est-à-dire l'union de deux ensembles de sommets. C'est aussi simple que ça.

Les trucs difficiles sont :
- Une astuce pour ne pas regarder les lignes qui ont été supprimées, sinon la complexité devient O(H).
- Des algos non-triviaux pour modéliser la résolution de conflits comme ajout de sommets.
- Un algo pour "désappliquer" un patch (la commande pijul unrecord).

Le seul point non-optimal est l'algo de diff, parce que le problème est NP-complet s'il y a un conflit, et on utilise un algo d'approximation.

Etant donné les différences d'approche, j'ai conscience que ça limiterait l'expression du potentiel de Pijul (pas de bijection: 2 commits git de même contenu ne matchant pas un même patch) mais penses-tu de la faisabilité ?

C'est totalement faisable, et sans doute pas très dur. C'est clairement la prochaine étapie, mais ce n'est pas encore écrit. J'ai connaissance de plusieurs tentatives, et j'étais jusqu'à maintenant assez occupé sur le reste (montrer que Pijul pouvait marcher, par exemple !).

Moi je trouve que depuis le début il répond très calmement et du mieux qu'il peut. Bravo à lui.

Du mieux que je peux, certes, mais c'est vrai que je dis des gros mots mathématiques, et que j'ai parfois mélangé les niveaux d'explications en peu vite, en alternant sans trop de transition entre rigueur mathématique et pratique quotidienne.

C'est vrai que dans la pratique quotidienne, Git marche plutôt bien. Je tombe régulièrement sur des cas pourris quand je sors un peu des clous (par exemple quand j'essaie de recomposer une version de NixOS déployable en production, sans tenir compte de mes dernières contributions à leur GitHub), mais sur des cas plus classiques ça passe.

Par contre, au niveau rigueur mathématique, on peut considérer Git comme "tout cassé", parce qu'il n'y a pas de preuve mathématique.

L'un des problèmes pour expliquer Pijul, c'est qu'il n'a pas ces cas pourris dans la pratique, et que ça vient de la théorie, donc il y a un moment ou on doit sauter de l'un à l'autre.

C'est très bien mais sois un peu indulgent et accorde un peu de temps aux autres qui découvrent.

Je comprends totalement, et je réalise que certains de mes commentaires ont pu paraître abrupts. Ce n'était pas mon intention.

Je saisis mieux cette notion de sous-ensemble dans lequel, le point central est que l'ordre n'a plus d'importance (sauf en cas de dépendance).

C'est exactement ça !

Mais même si c'est mal nommé le terme de "branche" est couramment admis.
En GCL (pardon de répéter ce gros mot) le terme consacré est variante pour ne pas présumer de la solution technique retenue.
Par exemple, on gère une variante pour la version (configuration :) que l'on maintient et une pour le dev en cours.
Dans les mal nommés "branching patterns", on parle de branchement par release.

Je ne connais absolument rien à ces patterns, mais je suis super intéressé. Si tu peux nous expliquer comment renommer nos concepts sur https://discourse.pijul.org, ce sera avec plaisir. On a déjà parlé de remplacer les noms "push" et "pull", de renommer les "patchs" en "changes" ou "contributions", et des gens se sont déjà plaints du nom "branche".

Bref, la terminologie est toute cassée, et n'aide pas à comprendre pour l'utilisateur qui vient de Git. D'autant plus qu'on a essayé de conserver les noms de commandes quand c'était possible, dans l'espoir d'être moins déroutant (l'idée est qu'un utilisateur basique de Git soit déjà un utilisateur presque complet de Pijul, il ne lui reste plus qu'à apprendre unrecord et rollback).

Ce que je comprends de tes interventions par contre, c'est qu'un autre branching pattern est en grande partie rendu caduc: Le branchement par feature.
C'est là où je pense qu'il serait utile de développer à d'autres occasions. Mais je crois que je vais m'y atteler car ça m'intéresse de creuser.

Avec plaisir ! N'hésite pas à nous rejoindre sur le discourse, ou même à envoyer des patchs sur le manuel (https://nest.pijul.com/pijul_org/manual)

Ou peut-être parce qu'il travaille sur des projets différent des tiens, parce qu'il veut un outil qui marche dans 100% des cas, et ne veut pas avoir à se plier à une discipline stricte quand ce n'est pas nécessaire.

D'autre part, les commentaires qui ignorent toutes les difficultés de Git me semblent de mauvaise foi : il y a quand même une commande git rerere, ça ne s'invente pas !

J'ai aussi répété au moins deux fois que c'était chouette que des gens aiment bien Git et se sentent productifs avec.

J'ai répété aussi que ce n'était pas mon cas, peut-être parce que ma façon de travailler (en général sur plein de trucs à la fois, souvent avec de petites équipes sur des sujets peu planifiables) ne se prête pas à la rigueur de Git.

C'est un résumé complètement tronqué de mon propos, qui se concentre sur un vocabulaire assez banal quand on essaie de décrire des algorithmes mathématiquement.

Au fil de mes commentaires, j'ai aussi décrit explicitement des cas où Git se trompe complètement, j'ai répété plusieurs fois que je l'utilisais régulièrement. J'ai parlé des workflows et des bonnes pratiques qui permettent de rester dans les clous pour des raisons purement techniques.

Et comme je l'ai dit plein de fois ici, je suis au courant (ayant un petit peu bossé sur le sujet) que Git marche souvent, dans plein de cas et pour plein de gens.

C'est un début, mais c'est sur la partie branche qu'on souhaiterait plus de matière.

Il n'y a pas besoin de branches dans Pijul, les patchs font le boulot. Elles sont implémentées pour faciliter la recomposition de versions, mais ce n'est pas le truc central.

Malheureusement, il n'y a pas grand chose à dire de plus dessus : une branche dans Pijul, c'est un ensemble de patchs, et c'est tout. On peut faire des unions d'ensembles, des intersections, déplacer des éléments entre les ensembles, mais il n'y a rien d'autre à comprendre.

Tu ne pouvais pas simplement répondre sans être sur la défensive, limite méprisant ?

Je ne sais pas à quoi tu fais référence. J'ai essayé de ne faire que des commentaires objectifs et rigoureux, je suis désolé si tu as mal pris un truc.

J'ai essayé de te donner un début d'exemple avec un fichier concret un peu comme ce qui est décrit ici pour Darcs:

Malheureusement, tout ce qui est décrit dans ce tutoriel sur Darcs est faisable avec Git, du temps, des pages de manuel, et plein de bonne volonté pour ignorer les cas pourris (les cas "à la marge", pour reprendre un de tes commentaires).

Je ne vois pas pourquoi les arguments que j'ai lus ici pour ignorer ces exemples seront différents.

Je crois que c'est moi qui vais m'y coller sur ce tuto parce que visiblement c'est un dialogue de sourds

J'ai déjà posté ce lien ici-même, par exemple : https://nest.pijul.com/tae/pijul-for-git-users

Je n'ai pas parlé de commit mais de graphe de patchs. Et il me semble bien que c'est le cas non ?

Certes, mais ça ne veut pas dire qu'on réarrange quoi que ce soit. Au contraire, on a une structure de données où on sait prouver que l'ordre n'importe pas, et donc que deux dépôts avec le même ensemble de patchs, même dans des ordres différents, sont équivalents sans qu'on n'ait besoin de "réarranger".

Après je suis désolé de t'importuner, mais pour moi un exemple concret, ça serait plus un tutoriel qui compare des actions git et pijul sur un repo avec un vrai fichier exemple et permettrait de montrer comment leur comportement diffère.

Bref, exactement ce que Jehan a développé.

Et sans vouloir te vexer, question tutoriels, Google ne m'a pas beaucoup aidé en ce sens.

Je ne suis pas du tout vexé ! Je sais bien que la doc n'est pas aussi étoffée que je voudrais. Ceci dit, les quelques exemples concrets qui ont été donnés ici (notamment le cas où Git mélange les lignes n'importe comment, mais pas seulement) ont été soit ignorés, soit commentés d'un "ok, Pijul le fait gratuitement, mais avec Git je peux faire la même chose en tapant cinq commandes, après avoir passé une heure à lire la doc et à régler des trucs à la main".

En effet, ceux qui ne restent pas dans la théorie s'intéressent au pragmatisme et préfèrent adopter des outils qui font le job.

Je voudrais juste rappeler qu'on discute d'un vrai outil ici, pas d'une hypothétique théorie.

Pijul a 20000 lignes de code. Il dépend de deux projets des mêmes auteurs :

• Thrussh, une implémentation complète de SSH en Rust, asynchrone, qui suit les états du protocole pour éviter les blagues. 10000 lignes de code.

• Sanakirja, un dictionnaire clef-valeur sur disque, transactionnel, avec une opération "clone" sans copie. 4000 lignes de code.

L'un des auteurs (Florent Becker) a aussi été l'un des plus gros contributeurs au projet Darcs.

De plus, autant Florent que moi-même sommes de gros utilisateurs de Git, de Darcs, et parfois de SVN.
Nous avons donc eu l'occasion de comparer très pragmatiquement ces outils avec Pijul.

C'est exactement la question que je me posais au sujet de ta réponse.

Celui qui dit c'est celui qui y est ? Aucune de mes réponses aux commentaires ici n'a été de mauvaise foi, ou n'a utilisé des exemples caricaturaux. Par contre, le coup des dix développeurs qui touchent la même fonction, il faut avouer que ça n'apporte pas grand chose au débat, on est tous d'accord qu'aucun outil ne va faire de miracle.

Je pense que la dichotomie entre les deux cas que tu décris montre bien en quoi Git transforme ses utilisateurs :

soit était triviales et pijul, git ou svn ne poserait pas de gros problème,

Avec Git, tout ce qui n'est pas à une personne et une branche n'est pas trivial. En gros, dès qu'il y a un merge sur le même fichier (même si les deux branches ont touché des morceaux très éloignés du fichier), il peut se passer n'importe quoi.

soit était signe de gros problèmes de design et demandais à redévelopper une partie d'une fonctionnalité

Là, on n'est carrément pas d'accord. Bien sûr, n'importe quoi de non-trivial sous Git demande de passer des heures à satisfaire les contraintes techniques de l'outil, de revoir la communication, de mieux former les collaborateurs du projet aux bonnes pratiques, de rendre le workflow plus rigoureux…

Parfois c'est aussi le cas dans d'autres systèmes de contrôle de version, bien sûr. Sauf que quand on travaille ensemble, la plupart des cas ne tombent dans aucune de tes deux catégories.

Dans mon expérience de programmeur et de co-auteur de textes en général, il y a plein de petits cas assez simples, mais pas complètement triviaux non plus. Bien sûr, on peut passer du temps à rebaser, à corriger les merges qui ont mélangé les lignes, à organiser ses branches en workflows. Mais avec un outil plus rigoureux, on pourrait aussi utiliser tout ce temps-là pour travailler sur le projet au lieu de satisfaire Git.

Exemple, dans l'écriture d'un projet comme Pijul, où les co-auteurs se font confiance et travaillent assez indépendamment sans se synchroniser outre mesure, il arrive qu'on ait des problèmes. Pourtant, vu qu'on travaille tous sur plein de sous-projets à la fois (parce qu'il y a beaucoup à faire, et qu'on n'est pas beaucoup), aucun de nous n'a envie d'adopter une structure rigide de branches, des merges temporaires pour vérifier que deux features passent bien ensemble, etc.

Un truc particulièrement difficile dans Pijul est que si on change la sortie d'un algo, il faut adapter tous les algos qui dépendait de cette sortie. Ça fait des gros patchs, mais avec Pijul on s'en sort très bien, je suis certain que Git nous aurait déjà donné du fil à retordre (j'utilise Git souvent).

Autre exemple, écrire un article en LaTeX. On travaille ensemble sur un peu tout, en s'échangeant parfois les parties à rédiger, à relire et à corriger. Parfois on fait des conneries, par exemple on résout mal un conflit. Ça peut arriver parce qu'on a choisi de travailler avec un co-auteur pour ses compétences en maths ou en littérature, pas parce qu'il maîtrise tel ou tel VCS. Il faut pouvoir virer le patch foireux, ou au moins en calculer l'inverse, même si ce patch résout un conflit ou "merge" des choses.

Quel va être l'apport de pijul rollback face à un git revert ?

pijul rollback marche pour 100% des patchs, même ceux qui créent ou résolvent des conflit, même sur des merges. Ce n'est pas le cas de git revert.

Ça ne dépend pas de ta deadline ou autre au contraire. Tu fais de une chose et tu l'intègre s'il y a un problème tu crée une nouvelle branche, je ne vois pas la complexité que ça apporte.

Il faut créer une nouvelle branche, la rebaser, l'entretenir, la fusionner. Bref, il faut réfléchir au contrôle de versions au lieu de réfléchir au vrai travail qu'on versionne.

Pour des projets pas trop compliqués, ou très bien planifiés, où on peut se permettre de prendre le temps pour penser aux rebases, aux créations de branches et aux merges, ça peut marcher.

Pour les projets sur lesquels je travaille, ça me fait perdre du temps.

Pijul n'est pas magique, 10 dev qui touchent le même fichier en parallèle, c'est pas un problème de gestion de version.

En effet, mais:
- dans Git c'est déjà la catastrophe avec deux.
- Pijul peut gérer les dix, puisque tu peux toujours revenir en arrière.

Cette remarque est-elle vraiment de bonne foi ?

Tout ce que tu décris en terme de réorganisation est possible avec le rebase de Git.

Certes. On peut aussi écrire tout ce qu'on veut en Brainfuck, c'est Turing-complet.

La question est, à quel coût ? Si on peut faire la même chose bien plus simplement, de manière plus déterministe, plus rigoureuse et plus concise, je ne comprends vraiment pas l'argument pour s'en priver.

(J'imagine que tu réarranges le graphe des patches en modifiant les arcs).

Il n'y a pas de DAG de commits dans Pijul, juste des ensembles de patchs.

C'est pourtant écrit dans la doc existante des dizaines de fois, je l'ai redit dans mon commentaire plus haut, c'est partout dans toute notre communication, et dans les tutoriels contribués par d'autres. Je doute que des tutoriels supplémentaires changent quoi que ce soit.

En tant qu'utilisateur, le format du repo m'importe peu

Oui, moi aussi je m'en fous, mais on nous l'a demandé. Apparemment tout le monde n'a pas les mêmes intérêts.

Par contre, voir à quoi ressemble la sortie d'une commande comme "add" "status" ou "log" m'apporterait.

Je ne suis pas sûr de comprendre. Pourquoi tu ne peux pas simplement faire pijul add, pijul status ou pijul log pour voir ça ?

Si tu juges utile d'avoir ça dans la doc, tu es le bienvenue pour faire un patch du manuel:

https://nest.pijul.com/pijul_org/manual

Quid de la séparation entre la synchro (fetch) et la mise à jour du workspace (merge)? Parfois c'est utile de ne pas recourir à un "git pull" et procéder en 2 temps.

C'est utile dans Git (je le fais souvent) parce que Git peut parfois déconner complètement quand il merge, et on veut pouvoir examiner le patch avant parce qu'on sait qu'on aura du mal à revenir en arrière. Dans Pijul, ce n'est pas implémenté, mais je doute franchement de l'utilité, parce que (1) Pijul a un algo de merge correct et (2) on peut toujours revenir en arrière, dans 100% des cas.

Comment tagguer une version ? Je lis dans la FAQ que ce n'est pas implémenté. Et surtout que les perfs risquent de s'en ressentir (O(n) vs O(1) pour git). De douloureux souvenirs s'éveillent en moi, ancien utilisateur de Clearcase et de SVN.

pijul tag existe pourtant, c'est dans la doc.

Dans la FAQ, il y a un paragraphe sur la navigation dans les versions. C'est plus subtile dans Pijul que dans Git, parce que Git est séquentiel, mais ce n'est pas non plus la mort dans Pijul. C'est même un peu plus flexible, puisqu'on peut composer une version avec seulement certains patchs.

Pour l'instant, on s'en sort à coups d'unrecord (la commande qui enlève des patchs). Pour le futur, on réfléchit à une interface plus efficace, qui tirerait partie de la puissance des ensembles de patchs, tout en restant au moins aussi simple que git checkout.

Qu'en est-il du .gitignore ? Je me vois mal être obligé de préciser moi-même explicitement tous les fichiers à versionner. Est-ce que l'option --recursive du add en tient compte ?

Pour --recursive, c'est pourtant dans la doc : https://pijul.org/manual/reference/add.html

Pour .gitignore, ce n'est pas dans la doc, mais c'est dans ce tutoriel : https://nest.pijul.com/tae/pijul-for-git-users

Ce n'est pas moi qui essaie de mettre en avant les atouts de mon projet. Un peu de pédagogie serait bienvenue. Les dépêches défilent et il n'est toujours question que de "théorie".

Je veux bien répondre à des questions sur des exemples "concrets", encore faut-il me donner ces exemples. Pourquoi les branches et commits dessinés en ascii art constituent des exemples concrets, et ma réponse non ?

Même si je comprends que tu préfères t'investir sur le projet, le temps d'écrire un tutoriel aurait largement été compensé par celui que tu passes à répondre ici ou sur reddit.

Je te suggère de cliquer sur l'onglet "documentation" de https://pijul.org, il conduit là : https://pijul.org/manual/

Il y a déjà de la doc, à laquelle on peut contribuer, poser des questions, etc. C'est un projet open source.

Si l'objectif est de comprendre, lire la doc existante et poser des questions peut aider. Si l'objectif est de se convaincre et de convaincre les autres que Git est mieux, lire la doc de Pijul ne sert pas forcément.

Je ne doute d'ailleurs pas du tout que Git soit mieux dans plein de cas, et pour plein de gens.

On peut laisser les commits dans l'historique : pijul rollback produit un patch qui en inverse un autre, les deux restent dans l'historique. pijul unrecord enlève des patchs de l'historique, mais ils sont toujours sur le système de fichiers.

Avoir de petites branches et les supprimer une fois mergé ne me paraît pas être une contrainte

Encore une fois, ça dépend à quel point tes bugs sont compliqués, de combien de personnes sont sur le projet, de la proximité de la deadline, du temps que tu veux consacrer à faire des rebase bien propres (pour satisfaire une contrainte technique de Git), etc.

Un "excellent/magique" VCS permettrait de lever un conflit ou tout au moins de préciser explicitement cette intégration.
J'attends toujours l'exemple concret qui montrerait que Pijul s'en sortirait mieux.

Ok, je te suggère d'essayer Pijul sur ce cas, tu verras qu'il fait le bon truc. Je ne vais pas te donner les exemples avec des diffs (mais tu ne me les donne pas non plus pour Git).

Le modèle de Pijul ici est que tu as trois ensembles de patchs:

• A: { a1, A1, a2, A2, a3, A3, a4, A4 }
• B: { b1, B1, b2, B2, b3, B3 }
• C: { c1, C1, c2, C2 }

Tu veux prendre des patchs dans A et les ajouter dans B:

pijul pull --from-branch A --to-branch B a1 A1 a2 A2 a3 A3

Tu veux prendre des patchs dans C et les ajouter dans B:

pijul pull --from-branch C --to-branch B -a

Maintenant tu as trois ensembles:

• A: { a1, A1, a2, A2, a3, A3, a4, A4 }
• B1: { a1, A1, a2, A2, a3, A3, b1, B1, b2, B2, b3, B3, c1, C1, c2, C2 }
• C: { c1, C1, c2, C2 }

Je les ai ordonnés par ordre alphabétique, parce que dans Pijul deux patchs produits sur des branches différentes peuvent être appliqués dans n'importe quel ordre sans changer le résultat (même s'il y a des conflits).

Si tu veux virer un ou plusieurs patchs (par exemple on veut virer b3, B3 et C2), tu peux faire :

pijul unrecord b3 B3 C2

J'attends aussi qu'on me démontre que la gymnastique intellectuelle que l'on doit appliquer afin de comprendre les cas où l'outil ne se comporterait pas comme on serait en droit de l'attendre, vaudrait de s'y investir.

Ma réponse est que le modèle de Pijul avec des ensembles est ultra simple. Il y a des preuves mathématiques que ça se comporte toujours "comme on s'y attend", c'est-à-dire que tous les conflits sont détectés, qu'ils sont résolubles par un seul patch, que les patchs sont associatifs ("pull AB, puis pull C" fait la même chose que "pull A, puis pull BC"), et que les patchs produits indépendamment commutent toujours.

C'est nous qui avons fait la gymnastique intellectuelle pour écrire cet outil, pas besoin de la refaire quand on l'utilise.

Désolé je ne saisis toujours pas. Lorsque tu parles de commuter des patchs en //, tu veux dire dans le cas d'un rebase ?

Peut-être y a-t-il un problème de vocabulaire. Quand je dis "les patchs commutent", ça ne veut pas dire qu'on doit les faire commuter manuellement, ça veut dire qu'on peut toujours les appliquer dans le désordre, et que ça n'a aucune importance, dans 100% des cas.

(les mots en gras sont importants).

Avec git, on obtient aussi le même résultat. Je ne vois toujours pas l'intérêt de cette commutation.

Même sur ce petit exemple simplifié, ce n'est déjà pas clair, parce que le rebase change l'identité des commits, HEAD peut être différent chez Alice et chez Bob, et la suite du travail génèrera de faux conflits qu'il faudra résoudre manuellement. Par contre, je suis d'accord que l'effet immédiat sur le texte, dans les cas où les heuristiques de Git arrivent à se rendre compte que les commits commutent (ça a de grandes chances d'être le cas ici, je n'ai pas essayé), est le même.

Dans le cas général, c'est encore plus faux, par exemple s'il y a des conflits, ça ne fait pas forcément la même chose (ne serait-ce que parce qu'il faut résoudre le conflit pour que Git accepte de rebaser).

Dans les deux cas, ça demande une opération manuelle consciente, alors que Pijul le fait automatiquement dans 100% des cas. Même si je suis d'accord que git rebase n'est pas très dur dans les cas simples, il faut quand même prendre le temps de réfléchir aux conséquences, à la disposition des branches, à ce qu'on veut faire après, etc. avant de le faire, ce qui peut engendrer (en tout cas dans mon propre travail) des pertes de temps d'autant plus importantes que la deadline est proche et que le vrai objectif du projet (qui n'est que rarement d'utiliser Git) est difficile.

Git ne gère pas vraiment ça dans 100% des cas, mais tu as raison, on voit qu'il aimerait bien simuler la commutation des patchs :

• Dans le cas des conflits, Git rerere ne se souvient pas vraiment du conflit, parce qu'il n'y a pas de représentation des conflits propre dans Git. Un conflit, c'est un merge qui n'a pas marché, il faut le résoudre. Git rerere est une heuristique pour essayer de se rappeler comment on a résolu la première fois, et ça marche dans plein de cas. Mais même si Git a des heuristiques qui marchent sans doute bien sur les exemples simples, il lui manquera de toute façon des informations.

• La commutation ne sert pas qu'à résoudre des conflits, ça sert aussi à éviter d'avoir à organiser son travail à l'avance très précisément. Il y a des cas (soit très simplifiés, soit très rigoureux) où ce n'est pas nécessaire. Dans tous les projets où je suis impliqué, c'est crucial. La seule exception (dans mon cas) est peut-être nixpkgs, mais même là, j'aimerais bien pouvoir composer mes versions comme je veux, sans avoir à perdre des heures dans des merges et des rebases que je vais devoir de toute façon défaire au bout d'un moment quand mes PR seront acceptées.

Ok, merci pour la remarque. Faire l'un et l'autre semble être une bonne idée.

La paire de patch qu'il décrit peuvent être produit en parallèle, c'est un fait.

Un truc caché dans cette notation des patchs, c'est le contexte dans lequel tu insères. Quand tu dis "+1 blabla", le "+1" fait implicitement référence aux lignes autour, il veut dire "après 0 et avant 2".

Donc le premier patch va faire référence à 0 et 2, si elles existent (ici 0 existe, c'est le fichier, et 2 n'existe pas).

Le deuxième patch fait référence à 0, 2 et 4. La ligne 4 n'existe pas, mais la ligne 2 oui.

Donc non, ces deux patchs ne pourraient pas être produits indépendamment en parallèle, parce que l'auteur du deuxième patch a besoin de connaître la ligne 2.

Au moment du regroupement de ces commits il faudra définir l'ordre c'est ça ?

Dans Pijul, l'ordre est automatique, et le reste de ta phrase est correct. En pratique, les patchs ne vivent pas vraiment dans un ensemble abstrait. L'utilisateur peut les voir comme ça, mais ils ont bien été appliqués au dépôt dans un certain ordre (qui peut varier parfois).

Pour moi un patch, (hormis la syntaxe du diff pour un cas simpliste), c'est
file.c:
+1, "blabla"

C'est (à peu de choses près) la même chose dans Pijul.

Si je commute les patchs, j'obtiens

Ah oui, sauf que là tes deux patchs ne sont pas productibles en parallèles. La règle dans Pijul, c'est que tu peux commuter deux patchs si et seulement si tes deux patchs sont productibles indépendamment. Ici, ton second patch dépend du premier, parce qu'il touche à des lignes voisines.

Pourrais-tu donner un exemple concret d'un patch avec Pijul ?

Je pense que ton exemple était déjà un bon exemple. Un autre exemple (que Git ne sait pas commuter) est l'exemple de deux patchs qui touchent à deux fichiers différents, ou à deux morceaux du même fichier, mais séparés par au moins une ligne.

Par exemple, après tes deux patchs:

En voilà du
blabla
Et patati et patata

Si Alice décidait d'écrire En voici du sur la première ligne, et Bob décidait d'écrire Et ron et ron au lieu de Et patati et patata, alors Alice et Bob pourraient appliquer leurs deux patchs dans n'importe quel ordre, ça donnerait le même résultat.

Pijul n'est rien de plus qu'un système qui permet de détecter les cas où l'ordre n'a pas d'importance, et qui sait calculer des inverses de patchs. Ce n'est que ça. Les autres systèmes ne savent pas faire ce truc qui a pourtant l'air tout bête, et nous on sait faire (en vrai ce n'est pas facile si on veut un truc qui marche dans 100% des cas).

Ce qu'on fait est tout-à-fait simple. Bien sûr, on peut en parler avec des tas de maths compliquées, et on doit en parler avec des maths pour certifier qu'il n'y aura absolument jamais de problème, mais à la fin ce n'est que ça (et c'est aussi pour ça qu'on a du mal à l'expliquer, parce que les systèmes existants ont habitué les gens à s'attendre à beaucoup plus compliqué pour simuler ça).

l'auteur de Pijul pourra librement se joindre à eux ;

J'habite en Irlande… mais je boirais une Guinness à votre santé !

l'auteur de Pijul devrait écrire une longue dépêche dans la foulée ;

Ce sera fait bientôt. Les réactions ici même m'ont appris pas mal de choses, merci à tous les participants (et n'hésitez pas à continuer) !

J'aime bien ton résumé.

les conflits de fusion sont encore à être traité par l'utilisateur pour avoir un fichier final cohérent.

Oui, si je savais régler tous les conflits sur un texte tout en satisfaisant tout le monde, je n'aurais pas écrit un logiciel, mais une lettre de motivation pour le Nobel de la paix.

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 :)

Tu as bien compris. Je n'ai annoncé ni une version 1.0, ni une version méga-optimisé, ni une doc de ouf. Juste le fait qu'on était enfin rassuré sur le fait que c'est possible. Florent et moi avons parlé de ce projet pour la première fois en Janvier 2014, on a commencé à l'implémenter à l'automne 2015 (on est resté bloqué longtemps parce qu'on n'avait pas de Sanakirja, et plein d'autres choses à faire).

je trouve léger de se repointer avec trois lignes de post et une doc officielle honnêtement indigne

… mais quand même tous les algos qui marchent, pour la première fois !

Tant qu'il y avait des montagnes de bugs que j'étais à peu près le seul à pouvoir attaquer, et qu'on ne savait pas que ça pouvait marcher complètement, la doc n'était pas vraiment une priorité (mais elle est quand même là, le manuel n'est pas indigne).

En plus, comme Pijul est un projet open source, on peut contribuer au manuel si on n'en est pas satisfait ;-)

pourquoi une ligne "ghostée" ne peut pas être "déghostée"? Dire "je remets un truc que j'avais supprimé" a de la valeur pour moi, c'est ce qui m'avais intéressé quand on passait sous git les textes de loi avec le bureau ouvert de l'assemblée nationale.

pijul rollback fait exactement ça, en produisant un patch qui annule les effets d'un autre.

git est orienté état, mais stocke des deltas dans les packfiles. pijul est orienté delta, mais pour la performance vous devez bien stocker des états non?

Il y a deux sujets, l'implémentation et les concepts. En vrai, je pense que tout système de contrôle de versions stocke ou utilise les deux à un moment ou à un autre (y compris Dropbox et Rsync). Même par mail on fait parfois les deux.

Dans Pijul, on stocke des diffs et des états (c'est la principale innovation par rapport à Darcs), mais l'utilisateur n'a absolument jamais besoin d'y penser. Git stocke des diffs et des états (et montre parfois les deux), mais l'objet auquel on doit penser quand on l'utilise est l'état.

vous utilisez les hard links comme le fait git?

Oui, pour "copier" des patchs quand on clone localement. En parlant de ça, je t'encourage aussi à regarder le design de Sanakirja, qui permet de cloner une "base de données" (dictionnaire clef-valeur) sur le disque sans rien copier.

dans les entrailles de git il y a le staging, la base git et le reflog… dans pijul il y a quoi à côte des graggles et de sanakirja? (Dans les entrailles de pijul il y a quoiiii!! sans avoir à lire du rust :D! Le blog de Joe Neeman est pas mal mais largement insuffisant et daté.)

J'ai commencé à documenter ça : https://pijul.org/manual/format.html

Mais Pijul a un fonctionnement un peu différent de Git, en particulier les structures de données sont plus tordues, et il est donc plus difficile d'y accéder sans… faire un peu de Rust. Ce n'est pas un "mauvais choix de design", c'est un peu une nécessité. Il y a malheureusement un compromis entre la lisibilité des structures de données et la complexité algorithmique des opérations dessus. Ceci dit, on a déjà réfléchi à refactoriser le backend pour le généraliser à des trucs moins efficaces mais plus lisibles (on n'a malheureusement pas de ressources en temps infinies).

Le manuel est aussi open source, il est possible de faire des commentaires (https://nest.pijul.com/pijul_org/manual/discussions/) et de contribuer. On a toujours répondu à toutes les questions qui nous ont été posées sur https://discourse.pijul.org, et presque toujours à celles posées par IRC (irc.freenode.net, #pijul).

votre fonction de hash?

Je suis un peu étonné par cette question, pourquoi c'est important ?

Pour l'instant il n'y en a qu'une implémentée, c'est SHA2-512 (si je me souviens bien), mais on peut la changer très facilement en restant rétro-compatible. On risque de changer la façon de l'utiliser dans les noms de fichiers, parce que les préfixes du base58 (ce qu'on fait aujourd'hui) du hash binaire ne sont pas des base58 des préfixes du hash binaire.

en quoi l'orienté delta de darcs et surtout pijul est une amélioration par rapport aux VCS précédents qui ont eu la même approche (j'avais lu que SVN est orienté delta?)? Bref une histoire en 10 tomes avec delta/état, centralisé/distribué, numéros de versions/hashs… des VCS serait plus que bienvenue.

SVN n'est pas du tout orienté delta, c'est (c'était?) un genre de Git où (commit+push) est une seule opération, que tu ne peux pas séparer. Bien sûr, tous les pushs sont fast-forward (comme dans Git).

L'amélioration numéro 1 c'est d'obéir à une théorie mathématique qui garantit des propriétés intuitives dans 100% des cas. Le seul autre système basé sur des diffs que je connaisse est Darcs (que j'aime beaucoup), et il gère très mal les conflits (mais les détecte très élégamment).

des benchmarks de performance et scaling entre VCS svp!

On n'en est pas encore là, on vient tout juste d'avoir des algos corrects. Avant de pouvoir benchmarker, on doit encore :

1. Améliorer l'utilisation du disque, et mieux gérer les gros fichiers binaires (pas évident, mais j'ai des idées).
2. Restreindre pijul record et pijul diff pour qu'ils ne regarde pas les fichiers dont la date n'a pas été modifiée (ça c'est facile)

Encore une fois, on est preneurs de bonnes volontés pour nous aider !

Peut-être serais-je encore plus efficace avec Pijul, qui sait! Ce n'est donc pas antithètique (être efficace avec git vs. Pijul est pour moi? Aucun rapport, fils unique!). 😛

D'abord, je ne me suis pas du tout senti "attaqué" par ton commentaire. J'essaie en général d'être rigoureux et concis dans mes réponses (et j'aime bien Git, je l'ai déjà dit).

D'autre part, Pijul étant significativement plus simple que Git, il n'est souvent pas complètement évident pour nous d'écrire de la doc. Pour avoir appris Pijul à des gens autour de moi, il me semble que la principale difficulté consiste à oublier les workflows, les bonnes pratiques, etc. Mais nous sommes complètement ouverts à des contributions, en particulier sur la documentation, comme tu peux le voir sur https://nest.pijul.com/pijul_org/manual/patches.

Je pense qu'une bonne façon de voir des exemples concrets, c'est d'essayer. Effectivement, le manuel n'est pas écrit en pensant aux gens qui vont vouloir comprendre tout Pijul sans jamais l'essayer, mais plutôt aux gens qui l'essaient et veulent comprendre comment ça marche (et pourquoi ça marche dans 100% des cas).

Je te suggère d'essayer tous les trucs dont j'ai parlé ici :

• essaie d'utiliser Pijul sans faire de branches. Ne fais que des clones dans un premier temps. Les branches de Pijul sont des clones rapides, mais comme la copie de travail est au même endroit, utiliser les branches peut cacher des trucs.
• essaie de pousser tes patchs sur https://nest.pijul.com, et fais des unrecord de vieux patchs dans l'onglet "patchs",
• essaie de faire des pull entre dépôts locaux sans prendre tous les patchs (du cherry-picking implicite).
• essaie de faire des conflits, d'éditer juste un côté et de faire record et push. Ensuite, dans un autre dépôt, pull seulement les patchs relatifs au côté que tu as édité. (A et B sont en conflit, C édite le morceau introduit par A. Pull juste A et C dans un dépôt séparé).

Tiens là par exemple j'ai vraiment du mal à comprendre ce que tu me dis. Comment la branche peut-elle être rebasée sans demande explicite?

Exemple concret d'un rebase d'une branche sur une autre : tu as une branche Git A, forkée depuis une branche Git B.

Pour faire plus concret:

       - y - z
     /
--- x -- u - v

Et tu veux la rebaser :

            - y - z
          /
--- x -- u - v

Dans Pijul, cette opération est parfaitement inutile, vu que les branches sont juste des patchs (il y a aussi un truc qui s'appelle "branche" dans Pijul, ce n'est pas la même chose). Dans Pijul, tu as juste deux ensembles de patchs, { x, y, z } et { x, u, v }. Si tu veux, tu peux appliquer un patch sur l'un des deux : { x, y, z, u }. Il n'y a pas d'opération spéciale pour faire ça, c'est juste appliquer un patch qui est dans une autre branche. Tu n'as pas besoin de réfléchir à la disposition de tes branches en le faisant.

Et tu pourras toujours revenir en arrière plus tard, même après avoir appliqué d'autres patchs. Concrètement : si tu as { x, y, z, u, a, b }, et que tu te rends compte que tu ne voulais pas u, ce que tu veux faire est "enlever u de l'ensemble", pas "dire que le parent de a devient z, puis essayer d'inverser le diff entre z et u".

Je suis d'accord que ça ne fait aucune différence sur les exemples simplifiés sur lesquels on explique généralement Git. Mais si tu imagine que u était en fait un merge avec conflit, qu'il a fallu plusieurs heures de travail d'un ingénieur cher pour résoudre les conflits et fabriquer u, et qu'on va peut-être vouloir le reprendre plus tard, tu peux imaginer le temps et l'argent perdu (par rapport à Pijul).

Et comme je l'ai déjà dit dans d'autres réponses, le modèle de Git oblige l'utilisateur à recharger un modèle mental du dépôt dans sa mémoire avant de commencer à taper des commandes. Ça n'a aucun inconvénient si ce modèle est simple (une seule branche, chaque commit ajoute une ligne, pas de conflits). Ça peut prendre du temps dans les autres cas. On pourrait répondre "oui mais tu vas bien devoir connaître ton dépôt quand même, pour travailler avec". Mon expérience (et celle des utilisateurs de Darcs et Pijul) est que c'est dû aux contraintes internes de Git, et que ce n'est souvent pas nécessaire.

Mais tu le retires-retires? Il n'est plus disponible du tout, plus de trace dans l'historique (genre pas comme un git revert où tu annules l'action du commit sans retirer dans l'historique)?

Ça reste un patch écrit dans un fichier, donc il existe encore, il n'est juste plus dans le dépôt. On peut le réappliquer.

C'est tout de même assez tendancieux de permettre la réécriture à volonté (pour les branches publiques, notamment communément celle appelée "master" dans git). Et ce n'est pas seulement car on casse l'historique dans git (les hashs de commit qui ne sont pas cassés dans Pijul, j'ai bien compris cette partie!), mais bien aussi car réécrire l'histoire, c'est perdre des informations.

Le morceau de mon commentaire auquel tu réponds ici était juste un exemple d'utilisation de rebase autre que "rebaser une branche sur une autre" dans Git.

J'ai déjà dit dans plusieurs autres commentaires que Git perdait de toute façon un peu d'informations en imposant la même histoire à tout le monde une fois un merge fini, alors qu'il y a eu en vrai ("concrètement") plusieurs histoires différentes qui ont produit la même chose.

En d'autres termes: Alice et Bob travaillent ensemble, Alice fait un patch A, Bob fait un patch B en parallèle. Après le merge, Git dit juste "A et B ont été fusionnés", alors que Pijul dit "Alice a appliqué A, puis B" et "Bob a appliqué B, puis A", et on a la garantie que les deux ont exactement la même chose dans 100% des cas.

Aussi les gens avec un vieux hash de commit ne peuvent plus le retrouver. Les seuls cas considérés comme acceptables sont normalement lorsqu'on a "commité" des infos méga-confidentielles par erreur (et encore… en général si on a fait ça, il faut surtout considérer que c'est trop tard cas on ne sait pas qui en a pris connaissance; donc réécrire l'histoire ne sert en général à rien, même dans ce cas, à part limiter les dégâts éventuellement le temps de changer les infos fuitées à la source).

J'ai l'impression que tu parles de bonnes pratiques Git. Je ne sais pas encore ce que peut être une bonne pratique dans Pijul, ni comment les gens vont vraiment l'utiliser. Git a plein de bonnes pratiques et de trucs "considérés comme acceptables" à cause de contraintes techniques, je ne sais pas quelles "bonnes pratiques" resteraient si on enlevaient ces contraintes (et je ne pense pas que quelqu'un puisse le savoir sans avoir essayé concrètement dans la vraie vie).

Mais ça veut dire quoi concrêtement une "vraie représentation interne des conflits", pour nous autres simples développeurs qui veulent juste versionner nos sources?

Ça veut dire que dans Pijul, un conflit n'est pas juste une erreur de fusion, c'est un état normal. Tu peux par exemple éditer l'un des côtés du conflit sans le résoudre, ou encore partager la résolution du conflit entre deux patchs sans avoir à partager tout le reste.

Avec des noms sur les patchs, ça donne : si tu as deux patchs A et B qui sont en conflit (par exemple, A écrit "a" dans un fichier, et B écrit "b" au même endroit), tu peux produire un patch C qui résout ce conflit. N'importe qui qui a les deux patchs A et B va voir le même conflit (indépendamment des autres patchs qu'ils pourraient avoir, par exemple s'ils ont d'autres patchs D ou E). Et à partir du moment où tu as A, B, et C dans le même dépôt, ce conflit est résolu. Il ne reviendra pas (au revoir, git rerere!).