pmeunier a écrit 108 commentaires

la jeunesse de l'implémentation en Rust de certains algos et protocoles de sécurité comme l'implémentation de ssh via votre projet Thrussh.

C'est compréhensible. Je t'invite quand même à examiner le code des différentes implémentations de SSH pour te faire une meilleure idée (Thrussh, OpenSSH, LibSSH).

Thrussh n'a pas eu la même quantité de tests que d'autres, mais le code suit à la lettre l'automate du protocole, avec une notion d'état encadrée assez strictement par l'API du crate Rust Tokio. Et Rust évite un paquet d'erreurs de C.

J'ai vachement hésité avant d'écrire ce commentaire car je vois bien que vous êtes un peu sur la défensive.

Ce n'est pas tout-à-fait exact. J'ai dû faire un peu de défense face à des commentaires de mauvaise foi. Et je comprends aussi qu'il est difficile de se défaire de ses préjugés, et qu'une maîtrise raisonnable de Git (personne ne le maîtrise vraiment à fond, parce qu'il fait des trucs aléatoires de temps en temps sans vraie raison) prend du temps et de l'énergie.

Car les algos prouvés scientifiquement c'est cool

Git est prouvé "scientifiquement", c'est-à-dire qu'il a été amélioré pragmatiquement au fil des années jusqu'à ce que des gens arrivent à s'en servir. Par contre, parfois il mélange des bouts de fichiers, et si on a le malheur de ne pas respecter ses "bonnes pratiques" et autres "workflows", il devient rapidement inutilisable.

Pijul est prouvé mathématiquement, ce qui veut dire qu'il implémente dans 100% des cas des axiomes mathématiques qu'on espère conformes à l'intuition.

Genre vous donnez 2 patchs (avec explicite diff) et vous montrez comment git le gère différemment (et surtout mal dans un cas) selon l'ordre

Comme je l'ai dit dans d'autres commentaires, l'ordre n'est pas le seul problème.

Et la page du manuel "Why Pijul" a bien un lien vers un exemple concret avec du code C, où Git s'emmêle les pinceaux (en termes mathématiques, où Git n'est pas associatif) : https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html

Sur la commutativité, tu as des exemples tout le temps quand tu utilises Git :

• Chaque fois que tu créés une branche dans Git : 99% des branches de Git se traduisent simplement par des patchs dans Pijul, vu que les patchs que tu pourrais faire en parallèle commutent toujours : pas besoin de les séparer, il seront séparables à n'importe quel moment dans le futur.

• Chaque fois que tu fais un rebase d'une branche sur une autre. C'est une opération qui n'est jamais nécessaire dans Pijul, elle est automatique dans 100% des cas.

• Rebase a d'autres usages, comme par exemple retirer un vieux commit. Pijul fait ça (la commande est unrecord) sans changer l'identité des nouveaux commits, donc si tu as déjà poussé ce n'est pas grave.

Comme tout le monde j'ai eu mes emmerdes avec des conflits de merge foireux dans git,

C'est un autre problème que Pijul n'a pas, il y a une vraie représentation interne des conflits.

Ça nous empêche pas de l'utiliser suffisamment efficacement pour nos besoins au quotidien.

Comme je l'ai déjà dit dans une autre réponse, si tu te sens efficace quand tu utilises Git, c'est très bien ! Peut-être que Pijul n'est pas pour toi.

Git a ses qualités, que j'apprécie. Je pense par exemple que dans un cas où on n'a jamais besoin de merge, c'est un outil quasiment parfait. Mais pour travailler à plusieurs sur du code ou des articles, c'est un outil qui fait perdre du temps à plein de gens. Il en fait évidemment gagner par rapport à ne pas utiliser de contrôle de version, utiliser Dropbox, SVN, des mails, mais je crois qu'il en fait perdre énormément par rapport à Pijul.

Ce qui prouve que l'usage final compte beaucoup

J'en suis convaincu, et c'est la raison d'être de Pijul.

L'idée est que si un outil répond à un raisonnement simple, déterministe, avec peu de commandes qui permettent de tout faire et marchent bien ensemble, je pense que son "usage final" sera plus facile qu'un outil à 150 commandes et 10000 options, dont les utilisateurs parodient le manuel : https://git-man-page-generator.lokaltog.net/

L'idée était de rendre super l'installation et l'utilisation super simple sur toutes les plateformes. Darcs est difficile à installer sous Windows, parce qu'il faut installer un agent SSH. Git est un peu mieux, mais ce n'est pas non plus évident.

Toutes les versions de SSH ne supportent pas les mêmes morceaux du protocole, et n'ont pas les mêmes options. En plus le fait de pouvoir écrire mon propre serveur avec Thrussh permet une interaction un peu plus fluide avec le Nest, par exemple (les messages d'erreur seront plus faciles à implémenter bien dans le futur).

C'est comme affirmer "un dessin est plus intuitif qu'un crayon". C'est du moins comme ça que je perçois cette phrase.

Je te suggère d'imaginer que tes interlocuteurs ne sont pas en train de délirer, et essaient vraiment de proposer un truc autre qu'un changement de vocabulaire.

Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif.

Ok, on va donc parler vocabulaire : un patch pour nous, c'est un ensemble de changements quelconque. On pourrait aussi dire un "diff". Laisser tomber tes préjugés deux minutes le temps de lire la dépêche aurait suffi à s'en rendre compte.

leur compréhension est assez aisée.

Non, plein d'utilisateurs de Git pensent que Git travaille avec des diffs, et ne comprennent pas toujours son comportement à cause de ça. Les commits ne sont "assez aisés" à comprendre que quand ils sont simples, qu'il n'y a pas ni conflits ni nécessité de rebaser.

tout ce qui m'intéresse, c'est, par exemple:

J'ai l'impression qu'on a les mêmes intérêts, et que c'est même pour ça que je pense qu'on peut faire mieux que Git:

est-ce que je peux l'apprendre tout seul comme un grand et l'utiliser?

Je rajouterais "en un temps raisonnable". Pour ça je prétends que travailler avec des diffs/patchs est largement plus facile à apprendre, d'abord parce qu'il y a un concept de moins (les commits), et surtout parce que le concept qui reste (les diffs) est très intuitif et très souple à utiliser (et d'ailleurs, c'est ce que Git montre à l'utilisateur).

est-ce qu'il me sauvegarde mes modif's sans me prendre la tête?

Git le fait souvent, pas toujours. Parfois il ne sauvegarde pas que tu as résolu un conflit, et te le remontre plus tard. Parfois il mélange tes additions avec celles de tes coauteurs. Parfois il supprime carrément toute une série d'additions parce que tu as voulu inverser juste un merge et envoyer l'inversion à tes coauteurs.

Pijul a été conçu pour n'avoir aucun de ces problèmes.

est-ce qu'il me fournit un historique de ce que j'ai fait?

Git est en effet super fort là-dessus, sauf qu'il en oublie un petit morceau (l'ordre dans lequel tu as travaillé localement après un merge). Pijul s'en rappelle

est-ce qu'il me permet de naviguer dans mes révisions?

Git ne sait naviguer que linéairement. Par exemple, si tu as fusionné une feature A puis une feature B sur ta branche master, avant de faire un commit C, et que les trois sont indépendants, tu ne peux pas simplement et facilement produire une version qui n'a que A et C.

est-ce qu'il me permet de défaire ce que j'ai fait?

Dans Git, pas toujours comme tu voudrais. En local, tu peux toujours. Si tu veux propager l'inverse d'un merge par exemple, c'est moins clair. Certes, si tu travailles tout seul, que tes branches sont relativement simples, tout va marcher, mais c'est dans les cas pourris qu'on a besoin d'un outil solide.

Pijul n'a pas ce problème, tous les patchs ont un unique inverse (et Pijul n'a que des patchs).

est-ce que je peux récupérer des modif's, individuelles ou groupées?

Dans Git, pas vraiment. Tu peux les "récupérer", mais pas les manipuler librement, pour une contrainte purement technique de Git : la raison pour laquelle Git force l'utilisateur à lui présenter un DAG de commits est simplement que les algos de merge qu'il connaît ne savent travailler que comme ça.

Donc si tu veux "récupérer" tes modifs, et les envoyer par exemple par mail, il faut d'abord les convertir en diff, et appliquer le diff dans de bonnes conditions, avant de tenter une fusion qui ne marche pas dans 100% des cas.

Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet.

Ok, je dois reconnaître que si tu as le temps et l'envie de faire ça, je suis un peu jaloux.

En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel

Les pages du manuel de Git, vraiment ? Il en existe même des parodies : https://git-man-page-generator.lokaltog.net/

Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git.

Je reconnais qu'il y a une certaine fierté à maîtriser un outil difficile à utiliser. Je suis moi-même content quand j'arrive à aller au bout d'un git rebase compliqué avec plusieurs co-auteurs, en prenant les changements de tout le monde en minimisant les conflits futurs.

Si tu aimes tes outils, c'est très bien ! C'est important pour bien travailler. Est-ce que ça veut dire que les gens qui ne s'en satisfont pas, ou qui préfèrent passer leur temps sur autre chose, sont nuls ? Je ne pense pas.

Par exemple git utilise des hard links pour avoir des clones locaux légers. Alors certes si on a pas ça on peut envisager un modèle plus worktree-style, mais avec ça aussi il y a des avantages et des inconvénients.

Le commentaire initial n'était clairement pas très informé, et supposait des trucs faux sur Pijul.

La structure de données que Pijul utilise pour représenter un dépôt est assez subtile, et ne pourrait sans doute pas être implémentée avec le seul système de fichiers, pour des questions de transactionalité.

en quoi ça disqualifirait pour être un "chercheur en informatique" (au contraire…)

C'était justement ce que je voulais dire : parfois, on doit utiliser des trucs plus subtiles, et pas seulement parce qu'on a "loupé un truc". Git arrive à être transactionnel (c'est-à-dire qu'il n'est jamais dans un état où un commit est à moitié fait) parce que sa structure de données de commits est un DAG de blobs.

Pijul a besoin d'une structure un peu plus subtile pour arriver à ses fins, parce qu'il fait des trucs que Git ne sait pas faire.

Ceci étant dit, je ne déteste pas le fait d'utiliser une DB

Je ne suis pas sûr de savoir ce que ça veut dire, il n'y a pas de "bases de donńees" dans Pijul, juste une structure de données qui a la complexité optimale pour les opérations qu'on veut faire dessus.

Il y a conflit ? Le merge est un graphe qui n'est pas une liste et il y a conflit à résoudre.

Justement pas trop, parce que le renommage ne produit pas juste une liste. Une façon de le représenter serait de rajouter un fichier "dictionnaire" à côté de chaque fichier. On représenterait toutes les variables dans le fichier original par des numéros, et le dictionnaire traduirait. Mais ce n'est pas trop ça.

Je ne suis pas sûr de savoir ce que sont les graggle, j'imagine que c'est le graphe des lignes. Tu as effectivement bien compris : le merge de O.p et O.q dans ton diagramme donne la même résultat que O.q.p et O.p.q.

commuter des patches (donc réécrire l'historique) ou encore faire des rebase après merge.

La seule raison pour laquelle "c'est considéré comme de mauvaises pratiques", c'est justement parce que Git ne permet pas de le faire proprement !

Gné ? On ne serait pas dans le syndrome du "not done here" ?

Non, mais si ça t'intéresse de comprendre, tu peux reposer la même question sans mépris ;-)

D'autre part il faudrait savoir, entre "tu ne fais pas d'UI" et "not done here". Quand on veut une bonne UI il y a parfois des trucs un peu casse-pieds à faire.

Je n'ai pas posé de question sur la théorie

Non, mais @dfroger en a posé une, je lui ai répondu. Un "workflow" de discussion assez classique à mon avis.

Tiens, je vais commencer. Mon workflow git (assez classique je pense):

Si tu es content avec ton workflow et ton git, c'est très bien, garde-le ! Ça a l'air en effet bien adapté à un gros projet qui roule déjà bien, avec des gens qui comprennent bien le problème qu'ils doivent résoudre, et qui prennent le temps d'organiser leur travail avant de commencer, qui travaillent sur des sous-projets bien délimités à l'avance, qui font rarement d'erreurs, et dont les bugs sont assez "locaux", c'est-à-dire pas trop intriqués les uns avec les autres. Si en plus ils ont le temps de réparer les merges et les rebases qui n'ont pas marché automatiquement, et qu'ils valorisent le respect des contraintes techniques de Git (les dites "bonnes pratiques") plus que leur temps de travail, que demande le peuple ?

Pijul essaie de gérer tous les autres cas, qui correspondent en fait assez bien à mon expérience de programmation et d'écriture d'article. Mon expérience est en fait pire, puisqu'elle est souvent la négation de tous ces trucs-là à la fois !

À savoir des gens qui s'attaquent à un problème inconnu, donc difficile à planifier à l'avance, qui travaillent sur des trucs trop durs pour eux, passent leur temps à devoir refactoriser à mesure qu'ils avancent, et dont la résolution d'un bug (1) soit nécessite de creuser assez profond en touchant à plein de choses (parfois seulement pour tester), (2) soit permet d'arriver dans un nouveau cas qui n'était pas géré, ce qui déclenche un nouveau bug. Et souvent, le temps est limité, soit parce que les gens compétents sur les trucs durs sont trop chers pour leur faire perdre du temps sur Git, soit (dans le cas d'un article) parce qu'il y a une deadline, et qu'on préfère faire des maths que faire du Git.

Il y a un coût caché non-négligeable dans ce type de projet, c'est le coût de changer de contexte. Si je suis en train de faire du code ou d'écrire du LaTeX, ça me demande souvent une concentration importante. Si j'ai à réfléchir à mes branches et mes rebases, et à réparer ce qui casse, je dois me remettre dans le problème après avoir réparé, et ça coûte du temps.

La plupart des problèmes que je rencontre aujourd'hui sont liés au merge, effectivement. Il me semble que la plupart du temps, des patchs sémantiques régleraient le problème, par exemple quand il les patchs concernent du coding style, du refactoring, etc.

Le plus gros problème est que le patch minimal n'est pas unique. Par extension, diff3 a parfois plusieurs choix, ce qui est assez inquiétant, parce que Git peut parfois mélanger des lignes un peu n'importe comment.

Suis-je donc le seul à rencontrer ces problèmes ? Pijul le résout-il ?

Non (de très loin), et oui, à 100%, sans patchs sémantiques.

La démarche de Pijul est intéressante (Je verrais bien cet algo mis dans Git un jour).

Les gens de Mercurial semblent y travailler, mais sans la commutation, c'est à mon avis nettement moins intéressant.

Néanmoins, ce que j'aimerais c'est un DVCS qui gère assez simplement les fichiers binaires ou du moins les fichiers "zip" comme les documents LibreOffice.

Il y a plusieurs difficultés :

• LibreOffice stocke son format en XML avant de le compresser. Pijul a besoin d'une structure de base du document, et d'opérations atomiques dessus. Sur une liste de lignes, c'est facile. Sur un arbre (XML), il faut travailler un peu plus. Ceci dit, comme XML stocke ses arbres dans des fichiers, on peut quand même faire un diff balise par balise au lieu de ligne par ligne.

• Représenter les conflits à l'utilisateur est sans doute assez compliqué, mais on peut y réfléchir.

• Les fichiers compressés/binaires ont parfois tendance à changer un peu partout à la fois, et sont peu structurés, donc on peut difficilement gérer les conflits efficacement.

En gros, on est ouvert à des contributions là-dessus ! https://discourse.pijul.org permet d'en discuter, et on peut t'aider à faire tes premiers patchs ;-)

Oui, bien sûr. Tu n'es pas obligé d'appliquer tout dans le même ordre, mais on ne doit jamais se retrouver dans un état où il manque des dépendances. Donc si B dépend de A (comme dans ton exemple), il faudra appliquer A avant B.

Désolé mais avec un tel discours, ton projet est mort.

En effet, surtout s'il est mal compris ! En réalité, ces features sont bel et bien implémentées, mais quand on me demande comment marche la théorie, j'essaie de l'expliquer en enlevant le plus possible de couches d'UI.

Par contre, ce n'est pas du tout la façon dont les auteurs de Pijul pensent les choses. Un petit tour sur notre discourse permet de se rendre compte de l'étendue des discussions sur les noms des commandes, leur composabilité, etc.

Pour avoir une UI de bonne qualité, fiable et portable, je suis même allé jusqu'à écrire une implémentation du protocole SSH en Rust !

En tant que développeur, j'ai vraiment autre chose à penser que la théorie d'un des outils que j'utilise 100 fois par jours.

Certes, mais:

• Quelqu'un qui pose la question a apparemment ça à penser.
• Git te remet le nez dans ses propres algos à chaque fois que tu travailles avec des gens. L'UI catastrophique de Git n'est pas du tout une excuse, bien au contraire.

Déjà, que git utilise en interne autre chose que ce que je vois, peu importe: en tant qu'utilisateur, c'est ce que je vois qui m'importe.

C'est un peu faux : si Git te montre des patchs, c'est qu'il sait qu'on a du mal à travailler avec autre chose !

Si les patchs étaient une représentation fidèle, dans 100% de cas, de ce qu'il y a dessous, ton commentaire serait vrai : d'ailleurs Pijul représente sa structure interne de manière un peu tordue, mais cette représentation est en bijection avec l'ensemble des patchs appliqués dans le dépôt.

Ce n'est pas le cas dans Git, où certains commits ne sont pas représentables par des patchs (des commits de fusion de branches, de résolution de conflits…).

La différence est loin d'être anecdotique : c'est justement dans les cas difficiles qu'on a besoin d'un bon système de contrôle de versions intuitif et déterministe, pas quand tout va bien, que l'historique est linéaire, qu'il n'y a jamais ni conflits ni rebases ni fusions.

La belle affaire: ça ne m'intéresse pas, bien au contraire.

Je n'y crois pas trop : sauf si tu utilises Git seulement dans ton coin en travaillant sur un seul bout de ton code à la fois, tu essaies de simuler la commutativité tout le temps avec Git, en utilisant des feature branches. Parfois ça marche, parfois il faut passer un temps plus ou moins important à rebaser.

Par exemple, plein d'utilisateurs un peu expérimentés de Git ont des astuces pour utiliser autre chose que git pull (qui vont de git pull --rebase à git fetch + git merge, et autres git rerere s'il y a un conflit), simplement parce qu'ils savent qu'ils ne vont plus jamais pouvoir faire commuter quoi que ce soit une fois le commit terminé.

La qualité et la sécurité du code exige que l'historique des sources soit immuable.

En fait "dans la vraie vie" c'est plus compliqué que ça. Dans Git, l'historique des sources devient artificiel à partir du moment où on rebase des trucs, ce qui arrive assez souvent quand on travaille à plusieurs, et/ou sur un projet un peu gros ou un peu compliqué. En forçant un historique identique pour tout le monde, Git oublie l'ordre local dans lequel on a travaillé, et oublie les relations de dépendances.

En plus, en forçant un historique séquentiel sur une branche donnée, Git force son utilisateur à organiser son travail en amont, alors qu'on sait bien qu'on ne travaille pas toujours sur du code selon un ordre établi à l'avance, en particulier quand on cherche à corriger un bug.

Si on parle de sécurité, je ne trouve pas très sécurisant d'avoir un algo de merge (tous ceux de Git ont ce problème) qui peut mélanger des lignes venant des deux branches un peu aléatoirement. Par contre, je serais content de pouvoir virer un vieux patch qui avait introduit une faille de sécurité, tout en gardant ce que j'ai fait après.

En résumé, je pense que "La qualité et la sécurité du code exigent":
- que les algos qui manipulent le code soient déterministes, prévisibles, et qu'on puisse les inverser si on fait une erreur. Git n'a aucune de ces propriétés à 100% (mais essaie de les avoir assez souvent).
- qu'on puisse savoir exactement ce qu'on envoie en production. Mais il n'y a pas besoin de version immutables tout le long du développement pour ça, bien au contraire, il suffit de pouvoir identifier un truc qui fonctionne.

Quand on dit que l'historique est séquentiel localement dans un dépôt, ça va veut dire les patchs ont un ordre localement dans chaque dépôt?

Oui, mais c'est plus du gadget d'interface utilisateur qu'autre chose, la théorie ne dépend absolument pas de ça. Dans le futur, on s'en servira aussi pour accélerer les transferts réseau.

Si Alice a comme patches P1, P2, P3 et Bob P1, P2, P4, et que Alice veut appliquer P4 et Bob P3, dirent que "les patches commuttent toujours", ça veut dire que Alice et Bob se retrouveront avec soit "code" avec le même, soit avec le même conflict à résoudre?

Oui, mais je le dirais un peu différemment: en fait je dirais qu'ils se retrouvent avec le même code, même si ce code contient des conflits.

La différence est un peu importante, parce que Pijul représente les conflits comme le cas "normal", il a même un algo pour détecter qu'un fichier est en conflit. Alors que (par exemple) Git ne stocke que des états sans conflits.

Je pense que vous avez manqué un point central du succès de git: contrairement aux autres VCS modernes, il n'utilise pas une BD !

Avec tout mon respect, je pense que c'est plutôt toi qui a dû louper un truc. Les auteurs de Pijul comprennent en fait assez bien Git, au moins assez pour en voir les limites.

Dans Pijul, il y a aussi plein de petits fichiers compressés avec Gz: des patchs, qui sont facilement exploitables pour faire des GUIs si on veut (nest.pijul.com est un exemple). Le problème, c'est que si on n'a que des patchs, l'expérience de Darcs montre que c'est difficile de faire un système efficace.

La "base de données" de Pijul est simplement une structure de données pour rendre le truc efficace. Il serait un peu triste de s'interdire d'utiliser des structures de données autres que des listes chaînées, surtout quand (comme les auteurs de Pijul) on se croit chercheurs en informatique.

D'autre part, la "base de données" n'est pas une obscure représentation tirée du chapeau, elle est totalement exploitable avec une bibliothèque existante, écrite en Rust (et donc interfaçable facilement avec C/C++, Python, Java, …).

Si on suit le raisonnement, Pijul est encore moins un "VCS", parce que dans Git, l'historique est au moins séquentiel, alors que dans Pijul, il ne l'est que localement dans chaque dépôt.

J'ai déjà répondu à une partie de cette remarque hier, ici même.

Git ne travaille pas avec des patchs, il en stocke parfois (uniquement pour des raisons de performance, ce sont les packfiles). Par contre, c'est vrai que Git n'expose pas ses entrailles à l'utilisateur "normal", et préfère montrer des patchs, parce que les patchs sont plus intuitifs que les commits (eh oui ! on n'a pas non plus écrit Pijul, Sanakirja, Thrussh… juste pour le plaisir).

Du point de vue purement théorique (en ignorant tout les outils qui vont autour), Git et Mercurial ne différent vraiment de SVN que par la possibilité de faire des branches. C'est une super innovation, qui enlève notamment le besoin d'avoir un serveur, et permet d'aller un peu plus vite.

Il y a d'autres changements massifs entre SVN et Git, par exemple la façon dont Git représente les dépôts est vraiment simple et élégante, alors que SVN avait une représentation toute pourrie (même Pijul a besoin d'une représentation assez tordue pour arriver à ses fins).

Je me cite dans une réponse antérieure:

Dans Pijul, deux patchs qui peuvent être produits en parallèle commutent toujours

Je vais modifier un peu ton exemple, parce que ton A et ton B ne sont pas productibles en parallèle dans Pijul (donc Pijul ne garantit pas la commutation dans ce cas).

Par contre, si A modifie un paragraphe, et que B ajoute une ligne au milieu de ce paragraphe, tu as raison, il y a bien un problème. Voici comment Pijul le résout :

Pijul manipule un graphe de lignes. Chaque sommet est une ligne, les arêtes ont un statut. Un patch est un ensemble:
- de nouveaux sommets et arêtes
- et de changements de statut d'arêtes.

(bien sûr, on peut faire des patchs qui ne font que l'un ou que l'autre)

Appliquer un patch, c'est appliquer ces changements au graphe (avec quelques optimisations pour que l'application d'un patch reste en complexité logarithmique en la taille de l'histoire). Note qu'il n'y a pas moyen de supprimer une ligne, on peut juste changer son statut (par exemple, la marquer supprimée).

Quand Alice ajoute une ligne dans un paragraphe, elle marque implicitement le contexte (j'appelle "contexte" la ligne d'avant et la ligne d'après) de cette ligne comme "vivant", alors que Bob le marque mort. Quand on fusionne les deux, on a un graphe valide, mais les lignes autour de la ligne d'Alice ont des arêtes vivantes et des arêtes mortes qui leur pointent dessus. C'est un conflit. On le signale à l'utilisateur (la façon de faire ça a changé énormément dans la nouvelle version, c'est devenu super simple), et on le laisse résoudre.

Remarque au passage que ce problème va se poser à partir du moment où Alice et Bob ont le même ensemble de patchs, même dans un ordre différent. Cependant, comme le contexte des lignes d'Alice est implicitement marqué vivant (et pas explicitement en rajoutant des arêtes), alors que Bob voit de nouvelles lignes avec un contexte qu'il a explicitement supprimé, la façon de le détecter doit être un peu subtile.

Pourquoi ne pas marquer le contexte explicitement ? Parce que pour faire ça, il faudrait rajouter des arêtes sur toutes les lignes qu'Alice considère vivantes, c'est-à-dire sur tout le fichier. Le patch d'Alice aurait alors tous les patchs qui ont touché au fichier comme dépendances, et donc les patchs ne pourraient commuter (on aurait donc juste un Git un peu plus lent, et avec des meilleurs merges).

Il y a une subtilité, qui a changé beaucoup dans la version 0.12, pour récupérer un patch qui parle du graphe à partir des changements de l'utilisateur dans un fichier.

1°/ être fiable (comme bazaar) pour le suivi du déplacement de fichiers

Il n'y a rien de magique ou d'heuristique dans Pijul, tout est basé sur des maths, et est déterministe (il peut y avoir des bugs, quand même).

Donc Pijul est même plus fiable là-dessus que Bazaar, parce qu'il gère proprement les conflits de déplacements fichiers.

2°/ avoir un format de patchs qui garde l'information concernant les blocs déplacés au sein d'un même fichier (ou entre fichiers, si c'était envisageable. Bref j'aimerais qu'un C-X C-V au sein du fichier ou entre différents fichiers soit encodé comme "tel bloc de données à été déplacé de X vers Y" et non comme un ajout+suppression…), mais j'ignore si c'est compatible avec ta théorie des patch et avec le format de données que tu envisages :),

J'aimerais bien avoir ça aussi, mais malheureusement, ça change pas mal la théorie : qu'est-ce qu'on est censé faire si Alice déplace un bloc vers le fichier A, pendant que Bob déplace le même bloc vers le fichier B en parallèle ?

On peut certainement ruser un peu dans pas mal de cas, mais l'idée de Pijul est de faire une théorie mathématique, c'est-à-dire une solution générale qui gère 100% des cas.
(par exemple aussi le cas où Charlie édite le même bloc sans le déplacer, en parallèle d'Alice et Bob).

3°/ cerise sur le gâteau : j'aime plutôt bien fossil pour sa simplicité et le fait que le repo entier est dans un unique fichier qui est une base sqlite : est-ce envisageable dans ton cas ?

Je ne trouve pas Fossil simple, je le trouve simpliste (je préfère Git et Mercurial). J'ai du mal à voir pourquoi SQLite est un bon choix pour faire ça, j'ai plutôt l'impression que c'est Fossil qui est un bon choix pour illustrer SQLite.

Notre backend est aussi une base de données (Sanakirja, dont j'ai aussi écrit un bon morceau), mais largement plus rapide que celle de SQLite, et avec une feature cruciale pour implémenter des branches sur une base de données sans faire aucune copie.

Et faire tenir tout dans un seul fichier est un peu contraire à l'idée de pouvoir échanger plein de petits patchs indépendants. Mais si tu n'as pas l'intention de pousser ou d'unrecorder des patchs, tu peux toujours garder juste le fichier .pijul/pristine/db et effacer tout le reste, ton dépôt marchera sans doute encore.

(en fait pour aller plus loin : imaginons qu'on conçoive un outil de diff/patch intégrant l'opcode "déplacement de bloc" mais par exemple aussi "indentation de bloc", "renommage d'une variable/refactoring", "suppression des espaces blancs" et d'autres choses => cela change t-il quelque chose à ta théorie des patchs ?)

Darcs fait une partie de ces choses. L'indentation ou les espaces, ce serait plutôt facile à ajouter dans Pijul, pour le reste j'ai un peu réfléchi à la question, et ça n'a pas l'air complètement évident : encore une fois, que doit-on faire si Alice et Bob décident en parallèle de renommer la même variable avec deux noms différents ?

Même mercurial qui tenait bien la route s'est fait enterrer par Git…

Mercurial n'apporte pas grand chose par rapport à Git, c'est essentiellement les mêmes algos, avec les mêmes merges, la même gestion des conflits. L'interface est un peu plus facile, mais moins rapide.

Au fait, il y a un GSoC Mercurial cette année pour tenter adopter l'algo de Pijul pour leurs merges.

Cela veut dire qu'on peut réécrire l'ordre de l'historique d'un projet ? Et si c'est le cas, n'est-ce pas une anti-feature ?

Ce n'est pas une anti-feature, pour trois raisons :

• D'abord parce qu'on peut rester "en mode Git" (en faisant des tags au lieu des records), c'est-à-dire que si l'ordre est vraiment important, on peut le maintenir si on veut. Dans ce cas, on ne profite pas à 100% de la commutation, dans le sens où on ne va plus pouvoir éditer les vieux patchs indépendamment des nouveaux. Par contre, dans ce cas, on a quand même des merges déterministes, et une algèbre claire et bien définie (ce qui n'est pas du tout le cas dans Git). Les conflits sont aussi gérés proprement (contrairement à Git, qui ne les représente simplement pas en interne).

• Ensuite parce que dès qu'on travaille à plusieurs, ou même sur plusieurs choses en même temps, le travail sur un projet n'est pas une suite linéaire de patchs. C'est Git qui a tort sur ce point, la "vraie" histoire est presque toujours plus compliquée.

• Dans Pijul, chaque dépôt a sa propre histoire, et Pijul la connaît (pijul log sait l'afficher, par exemple). Mais comme deux ensembles de patchs identiques produisent toujours le même résultat, même dans des ordres différents, l'ordre a largement moins d'importance que dans Git.

J'ai vu, merci ! Cette release me donne un peu de confiance pour écrire plus à propos de Pijul que pour écrire du code, donc je vais m'y atteler bientôt !

Donc qu'est ce que Pijul permet qui n'est fondamentalement pas possible de faire avec Git qui recalcul les patchs quand cela est nécessaire?

Pijul permet deux choses que Git ne peut pas faire:

• Dans Pijul, les patchs sont associatifs, ce qui veut dire que si on applique un patch A, puis B et C, on obtient le même résultat qu'en appliquant A et B, puis C. C'est assez intuitif, mais Git n'a pas cette propriété. Concrètement, ça veut dire que Git peut parfois prendre des lignes qui viennent de la fin du fichier, et les merger au début du fichier. Ça ne garantit pas que tous les merges donnent du code qui marche, mais au moins il y a une vraie structure mathématique, ce qui veut dire que le comportement est conforme à l'intuition.

• Dans Pijul, deux patchs qui peuvent être produits en parallèle commutent toujours, et ça change tout. La commutation élimine complètement le besoin de rebaser, et le cherry-picking devient l'opération par défaut, de manière complètement transparente. Par exemple, on peut cherry-picker plusieurs fois depuis la même branche sans craindre de ressusciter des conflits. La commutation de patchs élimine aussi largement l'utilité des branches, qui servent la plupart du temps dans Git à simuler la commutation de changements indépendants.

Pijul a aussi une vraie représentation interne des conflits, qui rend leur résolution plus facile : ce n'est pas juste un cas particulier bizarre, intermédiaire entre une tentative de merge local et le commit de merge. Dans Pijul, deux personnes avec le même ensemble de patchs voient les mêmes conflits.

Oublions pour un moment les problèmes d'UI (Git n'a pas besoin de serveur, SVN oui, et c'était casse-pieds. Git est vraiment mieux là-dessus, et d'ailleurs des non-techniciens peuvent l'utiliser même sans comprendre grand chose).

D'un point de vue théorique, Git et SVN sont tous les deux assez synchrones, dans le sens où ils forcent un ordre entre les opérations. On peut faire plus synchrone : Google Docs, par exemple, ou d'autres CRDTs. Git peut sembler un peu plus asynchrone que SVN, parce qu'il n'ordonne pas des opérations qui touchent à des branches différentes. Mais comme dans ce cas les opérations touchent nécessairement à des morceaux différents du dépôt, on ne peut pas vraiment parler d'asynchronisme.

Pijul, par contre, est complètement asynchrone : les contraintes d'ordre entre deux opérations sont réduites au strict minimum (essentiellement, on ne peut pas renommer un fichier, ou écrire dedans, avant d'avoir créé ce fichier). Dans Pijul, en dehors de cette contrainte, l'ordre n'a pas d'importance, puisque tous les ordres possibles aboutiraient au même résultat (les entrailles de Pijul sont mathématiquement un peu subtiles pour garantir ça, mais ça marche).

Mais comme les auteurs de Pijul font quand même du logiciel (y compris Pijul lui-même), ils comprennent quand même la contrainte des historiques clairs. Et dans Pijul, chaque branche se rappelle de l'ordre dans lequel les patchs ont été appliqués. Mais ça n'a pas d'importance, et d'ailleurs on peut enlever un patch en plein milieu (si les dépendances sont respectées) sans affecter le reste.

Avant Pijul, il y avait Darcs et Camp. Plus d'infos sur la clarté de l'historique là : https://www.youtube.com/watch?v=iOGmwA5yBn0

Il y a une structure de données interne qui modélise ton dépôt. Ton patch est créé, appliqué à cette structure de données, enregistré dans un fichier, et ajouté à l'historique de la branche.

Je ne suis pas sûr de savoir à quoi il est "relié", mais je pense que tu veux parler de ce que Pijul appelle des "dépendances", qui sont d'autres patchs. Si on voulait simuler Git avec Pijul, il suffirait que chaque nouveau patch ait le dernier patch comme unique dépendance (ce qui impliquerait qu'il a aussi tous les autres, par transitivité).

(si j'ai mal compris la question n'hésite pas à la reposer)

Est-ce que l'objectif est de défendre Git coûte que coûte, ou de comprendre mes arguments ? Dans le doute, je vais faire comme si c'était de comprendre mon argument.

Hum… Non ? git t'oblige à avoir une copie de travail (clone), ensuite le fait de faire une branche c'est juste une bonne pratique.

C'est un peu plus qu'une bonne pratique, c'est la seule solution pour faire commuter des patchs indépendants, et le seul avantage de Git sur SVN (un gros avantage, on est d'accord). La commutation du travail est la principale intuition derrière le contrôle de versions distribué, c'est le truc que les algos de merge de Git essaient de simuler.

Tu peux très bien te retrouver avec un historique non linéaire en git, mais tu va te faire mal. C'est pas de la faute de git.

100% d'accord, mais je maintiens que ce n'est pas pour une bonne raison, c'est juste parce que Git ne me laisse pas parler de patchs sans avoir à rebaser (un peu comme à l'époque où SVN ne me laissait pas parler de commit sans avoir à merger).

Comprendre un historique non linéaire est une plaie. Trouver une erreur dans une jungle de patch est à des magnitudes plus compliquées qu'avec un log linéaire.

Je suis partiellement d'accord, et c'est d'ailleurs pour ça que Pijul a les deux. Dans Pijul, une branche a un historique linéaire et un ensemble de patchs.

Ça permet d'enlever des patchs presque n'importe où dans l'historique sans avoir à rebaser. Et deux historiques qui contiennent les mêmes patchs, même pas forcément dans le même ordre, produisent toujours les mêmes fichiers (ce n'est pas toujours le cas dans Git, même quand les commits ont été mis dans le même ordre à coups de rebase).

Pour trouver une erreur, j'imagine que tu fais référence à git bisect. C'est carrémment possible dans Pijul, même si on ne l'a pas encore implémenté, et on peut même isoler des ensembles de patchs bien plus finement que dans Git.

Merger plus de 2 fichiers est aussi bien plus compliqué, déjà qu'en merger 2 est casse gueule.

C'est vrai quand on merge avec une "heuristique qui marche souvent". Quand on a un algo de merge qui vérifie certains axiomes pratiques, et où tout est réversible, c'est plus facile. Bien entendu, travailler ensemble et se mettre d'accord c'est dur dans la vraie vie, donc fusionner des changements l'est aussi. Mais au moins, Pijul ne le rend pas plus dur que la vraie vie en introduisant des sources d'erreurs techniques.

C'est vraiment décidable d'avoir A(B(C())) == A(C(B())) ?

Dans Pijul la commutation BC=CB est décidable, parce que des patchs qui ne commutent pas se référencent toujours explicitement (ou via une chaîne de dépendances), donc des patchs créés indépendamment commutent toujours (donc c'est décidable). À ce sujet, dans Darcs, la commutation est décidable sans conflits, et avec des conflits non-triviaux je ne comprends pas trop ce qu'il fait.

Mais là, c'est plutôt A(BC) == (AB)C. Et c'est décidable si A, B et C sont des patchs produits par Pijul, puisque c'est toujours le cas (une machine de Turing qui voudrait le décider s'arrêterait tout de suite sans regarder les patchs, et répondrait "oui").

Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer.

Et d'ailleurs, Pijul peut même améliorer la qualité de l'historique par rapport à Git ! Vu que Pijul n'a pas besoin de rebaser des changements pour les appliquer sur une autre branche, on peut retracer l'historique des changements, qui serait complètement perdus sinon. C'est bien pratique quand on a une branche instable et une branche stable, par exemple, et qu'on fait passer les correctifs de bugs de la branche instable à la branche stable.

Ça, en Git, ce serait un cauchemar, géré à coups de rebases et autres "rerere", au prix de longues et stressantes heures de travail qui auraient peut-être été mieux investies à réfléchir à l'algo ou à écrire du code.

Surtout que je ne vois pas la contrainte que cela pose. Éventuellement tu peux me parler du fait que ça contraint celui qui veux fusionner son code à faire en sorte qu'il fusionne correctement.

Clairement, quand on travaille tout seul sur une histoire linéaire, ou qu'on s'organise suffisamment bien pour découper le projet à l'avance sans jamais changer radicalement d'organisation, Git ne pose aucune contrainte.

Mais dès qu'on bosse sur un projet un peu moins bien défini, ou qu'on veut revenir en arrière de façon un peu non-triviale (annuler le patch d'avant-hier, mais pas celui d'hier), ou fusionner des branches temporairement, ou "cueillir des cerises", ça devient super contraint.

Attention, je n'ai pas dit impossible, Git permet bien de faire tout ce qu'on veut. J'ai juste dit "contraint", ce qui implique que ça engendre des coûts de maintenance importants dans certains projets.

Pas besoin de savoir ce que veut dire "théorie des patchs" pour l'utiliser. En vrai, c'est une structure de données qui garantit que les patchs se comportent bien, c'est-à-dire qu'ils vérifient certains axiomes :

• commutation : deux patchs produits indépendamment peuvent être appliqués dans n'importe quel ordre sans que cela ait d'influence sur le résultat.
• associativité : appliquer deux patchs en même temps fait la même chose que les appliquer individuellement, i.e. appliquer d'abord A, puis B et C ensemble fait la même chose que A et B ensemble, suivis de C.
• inverse : tous les patchs ont un inverse, qui est un autre patch que je peux envoyer pour "annuler" mes changements. Dans Pijul, absolument tous les patchs qui résolvent des conflits ont un inverse.

Mais le pari de Pijul, c'est qu'en vrai, on n'a pas besoin de savoir ça. La théorie des patchs en pratique, ça veut juste dire que tout se passe conformément à l'intuition. Dans Pijul, les branches ne servent qu'à suivre plusieurs versions du projet en parallèle (branche stable et instable, par exemple, mais pas besoin de branches pour contribuer à un projet).

Répondre à un troll est-il un art ? On va essayer en tout cas…

Je suis heureux avec Git, et j'ai pas envie de tout changer, […]

Je suis content que tu sois heureux, évidemment. Je ne suis moi-même pas malheureux avec Git, je l'utilise régulièrement pour contribuer à différents projets, avec ou sans GitHub.

Mais comme je l'utilise quand même beaucoup, et que je sais un peu comment il marche, je sais aussi qu'il a de gros problèmes, par exemple quand on essaie de l'utiliser soit un peu trop vite (en essayant d'être un peu trop "agile", à l'approche d'une deadline par exemple), soit avec un peu trop d'utilisateurs. Ces problèmes, ainsi que les problèmes d'UI sont théoriques

• Le premier problème de Git est le manque de commutation des changements :

  • Git oblige ses utilisateurs à forker (brancher) les dépôts alors qu'ils voudraient en réalité envoyer un patch pour faire avancer le projet. Cette différence, qui, je te l'accorde, paraît évidente après des années de Git, n'a rien de naturel. Et d'ailleurs, git log -p affiche un patch (des changements), pas un commit (une version) !
  • Git séquentialise tout. Si je veux combiner des changements depuis plusieurs branches librement, il faut que je choisisse un ordre, même si les commits ont été produits en même temps. Ça encore, ça n'a rien de naturel ! D'autant plus que comme Git n'a pas de vrai algo de merge, l'ordre que je choisis ne fera pas forcément la même chose, je ne verrai pas les mêmes conflits, et même sans conflits, parfois pas les mêmes fichiers !

• Le deuxième problème de Git est l'absence d'associativité des changements. Si je git commit A, puis que je git pull B et C en même temps, ça ne fait pas toujours la même chose que si je commit A, puis que je git pull B, puis git pull C. Ça, c'est parce que l'algo de merge de Git est un algo d'optimisation que a parfois plusieurs solutions, auquel cas il en choisit une arbitrairement (sans même en avertir l'utilisateur). Et ça arrive même en l'absence de conflits.

Pourquoi Git fait ça comme ça ? La réponse est purement technique, c'est parce que gérer des patchs, ça rend les changements asynchrones, et qu'on ne comprend pas grand chose à l'asynchronisme, en pratique comme en théorie. C'est pour ça que Git séquentialise tout. C'est ça qui le rend monstrueusement rapide et relativement économe en espace disque (ça, et 10 ans de développement d'une grosse communauté).

Mais Git contraint les projets un peu trop gros ou un peu trop agiles à une organisation très rigoureuse, qui n'a pas souvent grand chose à voir avec les contraintes du projet. Je travaille régulièrement sur des projets suffisament contraints par ailleurs (des articles de recherche ou du code scientifique) pour ne pas vouloir me rajouter des bâtons dans les roues exprès.

[…] tout ré-apprendre.
un nouveau VCS que je suppose réécrit from scratch. Stop, j’ai pas fini de faire le tour de Git.

Tout ré-apprendre, non! Apprendre RCS, CVS, SVN, Git prend du temps et ne finit jamais vraiment, parce qu'il n'y a pas d'algorithme propre derrière, ces outils marchent la plupart du temps, mais (1) ne modélisent pas très bien le problème de travail collaboratif, et (2) sont contraints, pour une raison ou pour une autre, à utiliser des heuristiques au lieu d'algos bien définis.

C'est un peu la même situation que les langages système avant C et Unix : tout le monde faisait une tambouille qui ne marchait pas trop mal, mais il a suffi d'un design rationnel comme C (même s'il n'est pas parfait) pour qu'on n'entende plus trop parler des BASIC, FORTRAN et autres COBOL (bien sûr, ces langages existent encore, mais ils ont été marginalisés et/ou forcés d'adopter des features de C, comme malloc et free pour FORTRAN, par exemple).

en Rust. Question de mode ? Stop, j’ai pas fini de faire le tour de C/C++

Pour la même raison, on peut imaginer que personne ne "fera jamais le tour" de C et C++. En tant que programmeur (et chercheur en info), j'aime bien voir une machine basée sur une théorie rationnelle travailler pour moi. C'est peut-être une satisfaction marxiste, et très clairement une satisfaction moderniste, mais c'est une satisfaction quand même.

Si une machine peut vérifier mon code pour moi, pourquoi vouloir à tout prix le faire à la main ? Le code que j'écris en Rust n'est pas très différent de ce que j'écrirais en C++, mais il est entièrement vérifiable par un algo basé sur une théorie cohérente. En utilisant ce genre de langage, je passe mon temps à écrire du code presque correct, et à laisser le compilateur me guider pour finir de l'écrire correctement.

En C, je passerais mon temps à débugger des erreurs d'allocation mémoire ou de concurrence, et je continuerais à les faire jusqu'à la fin des temps, parce que je suis un être humain. En Rust, je fais ces erreurs aussi, mais plutôt que de passer une semaine à les corriger, le compilateur Rust me les signale en quelques millisecondes.

écriture d’une lib SSH en Rust. Hein ? Ouais, je sais, c’était pas forcément mieux avant, toussa. Mais pourquoi tout refaire ? Pour ajouter de nouvelles failles ?

Ça c'est facile. Ce ne sont bien sûr pas mes oignons, mais à l'avenir, pour des trolls de meilleure qualité, je te conseille de te documenter un peu mieux.

La motivation de la lib SSH, c'est simplement parce qu'il n'existait pas de bibliothèque SSH en C pour écrire un serveur, qui soit documentée correctement. Et la seule bibliothèque utilisable pour écrire un serveur (libssh) est bourrée de failles un peu triviales, est très mal documentée, et son code est assez horrible.

Écrire ça en Rust permet d'écrire (pour la première fois) un serveur avec quasiment les perf de C++, avec un automate de protocole clairement défini qui évite plein de failles classiques (je n'ai aucun mérite, ça marche juste parce qu'une machine le vérifie), avec une API super modulaire et facile à utiliser.

et pourquoi SSH ? OK, j'ai pas cherché à savoir, mais si je veux du SSH, j'utilise ssh, pas Git. Chacun son taff.

Qui a dit que Pijul remplace SSH ? Comme quoi parfois il vaut mieux chercher un peu à savoir…

J'espère ne pas avoir sorti trop de choses de leur contexte. Je choisis de ne pas répondre au "point systemd", sorte de point Godwin du geek Debian. Tu es vraiment un Hitler du contrôle de version !