Salut ! Je suis un des auteurs de Pijul, et en retard pour répondre.
C'est dommage que sa doc se focalise sur un avantage futile (youpi, mes merges sont supposément plus fiables) plutôt que sur des avantages concrets dans 100% des cas (mon repo est 100% fiable, validable et ne peut pas techniquement être corrompu sans rattrapage possible).
Ces avantages "concrets" sont bien évidemment garantis par notre théorie. L'avantage des merge n'est certes pas le principal avantage, mais l'idée d'avoir une théorie petite, qui garantit un petit nombre d'axiomes simples, est un avantage énorme.
Et d'ailleurs, si on regarde les bonnes pratiques, les "successful workflows" et autres "Pro Git Book" en connaissant ces axiomes, on se rend compte que tout le monde cherche à garantir la même chose.
Maintenant, (sauf dans le cas rare de Git is inconsistent, où Git fait vraiment n'importe quoi), il y a deux façons de garantir ces propritétés : soit c'est la machine qui le fait, soit c'est le programmeur. C'est exactement la même différence qu'entre la programmation fonctionnelle et les autres langages. Il n'est d'ailleurs pas extraordinairement surprenant de voir des utilisateurs de Rust, Haskell, OCaml, Scala etc. désirer mieux que Git.
Notre pari, c'est qu'alors que les langages fonctionnels sont plus difficiles d'accès que Python, pour nous ça a l'air d'être l'inverse : l'utilisateur peut complètement oublier qu'il y a une théorie derrière, tout ce qu'il voit ce que "ça colle à l'intuition" (c'est à ça que servent des axiomes dans toutes les théories) et que "ça va vite".
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 10.
Salut ! Je suis un des auteurs de Pijul, et en retard pour répondre.
Ces avantages "concrets" sont bien évidemment garantis par notre théorie. L'avantage des merge n'est certes pas le principal avantage, mais l'idée d'avoir une théorie petite, qui garantit un petit nombre d'axiomes simples, est un avantage énorme.
Et d'ailleurs, si on regarde les bonnes pratiques, les "successful workflows" et autres "Pro Git Book" en connaissant ces axiomes, on se rend compte que tout le monde cherche à garantir la même chose.
Maintenant, (sauf dans le cas rare de Git is inconsistent, où Git fait vraiment n'importe quoi), il y a deux façons de garantir ces propritétés : soit c'est la machine qui le fait, soit c'est le programmeur. C'est exactement la même différence qu'entre la programmation fonctionnelle et les autres langages. Il n'est d'ailleurs pas extraordinairement surprenant de voir des utilisateurs de Rust, Haskell, OCaml, Scala etc. désirer mieux que Git.
Notre pari, c'est qu'alors que les langages fonctionnels sont plus difficiles d'accès que Python, pour nous ça a l'air d'être l'inverse : l'utilisateur peut complètement oublier qu'il y a une théorie derrière, tout ce qu'il voit ce que "ça colle à l'intuition" (c'est à ça que servent des axiomes dans toutes les théories) et que "ça va vite".