pmeunier a écrit 114 commentaires

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!).

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 !