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.
[^] # Re: Difference Pijul vs Git
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
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.