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/
[^] # Re: Exemples concrets?
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 5.
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.
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.
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.C'est un autre problème que Pijul n'a pas, il y a une vraie représentation interne des conflits.
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.
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/