pmeunier a écrit 114 commentaires

Oui, mais je parlais dans mon dernier commentaire d'un cas où git rerere est utile. Pour voir une différence entre Git et Pijul, il faut vraiment que C résolve le conflit en laissant les lignes de A et de B. { A, B, C } (désolé pour les dépendances) donne :

a
b

Si C résout le conflit en supprimant les deux lignes, et que F fait autre chose, tu vas voir un nouveau conflit, quel que soit l'outil que tu utilises. C'est simplement parce que "tadaaa", ce n'est pas la même chose que "tadaa". Un outil qui ne verrait pas de conflit sur ce cas serait foireux.

C'est exactement ça. Tu n'es pas allé assez loin pour avoir besoin d'un rerere.

Pour simplifier un peu, on va dire que C ne fait que garder toutes les lignes de A et B, dans l'ordre où elles sont affichées.

Maintenant, la personne qui a produit B continue à travailler, pour produire par exemple F (on pourrait dire que F change toutes les lignes introduites par B, et ne fait que ça).

Elle a donc un dépôt e_3 = {B, F}. Si maintenant tu pulles son dépôt depuis e_2, tu vas te retrouver dans Pijul avec {A<-C->B, D<-E, F}, et dans Git avec un nouveau conflit sorti de nulle part, qu'un git rerere au moment de produire C aurait résolu.

D'après vous, pourquoi Linus Torvalds n'a pas utilisé ce concept pour git ?

Je ne sais pas, mais il y a plusieurs bonnes raisons :

• SVN et CVS avaient le même genre de concepts de développement "séquentiel", et la plupart des développeurs savaient les utiliser. Git l'a juste rendu plus simple et (presque) distribué.

• Faire un prototype de Git n'est pas très dur, une fois qu'on a les bonnes idées (qui étaient déjà dans l'air, Torvalds a aussi ajouté quelques trucs nouveaux).

• Darcs avait de gros problèmes de performance. Avant Darcs 2 (2008), c'était catastrophique. Avant Pijul (proto en 2015, version qui marche en 2019), on ne savait pas si on pouvait faire un système basé sur des patchs plus efficace qu'exponentiel dans le pire cas.

Torvalds connaît Darcs et Pijul. Il voyait Darcs comme une bêtise purement académique (à cause des performances), mais n'a rien contre Pijul.

Je ne crois pas que lui ou nous pensent que Git et Pijul doivent être concurrents, ils ne servent pas vraiment à la même chose.

Pour info, Erlang n'est pas du tout académique et provient de l'industrie des télécoms.

Bien sûr, je parlais de "curiosité académique" dans le sens "théorie qui ne sert à rien". Et ni OCaml, ni Haskell, ni NixOS, ni Pijul n'ont comme motivation la pureté théorique, bien au contraire.

La version 12 de Pijul devrait arriver bientôt. Elle est pour l'instant un peu compliquée à compiler, il faut bricoler un peu Carnix avant d'y arriver, et trouver une solution pérenne à l'accumulation de vieux crates dans nixpkgs.

En lisant ces messages, j'ai un peu l'impression de lire le discours des Linuxiens qui n'ont pas touché à Windows depuis 20 ans et qui essayent d'argumenter que Windows, c'est de la merde, ça plante tout le temps et il faut reformater le disque et réinstaller toutes les semaines

Pardon, j'avais loupé cette accusation particulièrement grossière. Je ne vois ni le rapport avec le sujet, ni en quoi ça fait avancer la discussion. Je ne sais pas où j'aurais dit un truc pareil.

C'est con, parce que si tu voulais une comparaison entre un truc d'ingénierie "qui-marche-somme-toute-pas-mal" et un truc qui vient d'une théorie propre, il y avait d'autres exemples largement plus à propos :

• Tu pouvais parler par exemple de OCaml, Haskell, Erlang, des curiosités académiques, que les programmeurs Java prenent de haut, parce que "Java/C++ ça marche bien quand même", "c'est toi le problème, si tu définis pas tes classes proprement". Bien sûr, ça n'aurait pas trop alimenté ta hargne, parce qu'aujourd'hui ces langages sont mainstream. Mais on ne peut pas non plus être tout le temps hargneux.

• En moins consensuel (parce que plus récent), tu aurais pu tenter un troll sur NixOS (issu d'une thèse) contre Debian ou RedHat (les standards qui marchent-bien-quand-même). Tu aurais pu dire que ce n'est quand même pas la mort de lire des pages de manuel Debian pendant des heures pour pouvoir faire un brouillon de package pour "GNU Hello", à perfectionner pour éviter qu'il casse à la première mise à jour.

En effet, désolé pour le malentendu.

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

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

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

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

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

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

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

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

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

Donc non !

Pourrais-tu développer un peu ?

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

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

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

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

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

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

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

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

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

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

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

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

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

C'est exactement ça !

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cette remarque est-elle vraiment de bonne foi ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Maintenant tu as trois ensembles:

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

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

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

pijul unrecord b3 B3 C2

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

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

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

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

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

(les mots en gras sont importants).

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

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

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

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

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

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

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

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