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!).
J'avoue que ça reste encore un peu flou, alors j'essaye de détailler.
Afin de lever toute ambiguïté, je te propose d'utiliser la terminologie suivante (Je sais que vous y réfléchissez encore et j'ai pas mal cogité et bidouillé de mon côté ;-) :
Toute branche au sens de Pijul est appelée ensemble car ce n'est ni plus ni moins que ça - un ensemble de patchs (change) atomiques et de séquences de patch (interdépendants et ordonnés) -.
Par exemple, si on a 2 sous-ensembles dans notre dépôt: e1={A} et e2={A, D<-E}.
Chacune de ces entités (unités de changement ou séquences) commutent entre elles. On a, de par la commutativité: {A, D<-E} == {D<-E, A} != {E<-D, A}
(Une séquence ne commute pas entre ses propre constituants mais commute avec les autres entités).
Jusque là, j'ai juste ?
Admettons que l'on incorpore un nouveau change ( pijul pull ) B dans e1 qui entre en conflit et que l'on doive évidemment le résoudre avant de l'intégrer ce qui donne C comme dépendance. ( pijul dependencies)
Si te je suis toujours, on obtient à présent: e1={A<-C->B}, e2={A, D<-E}
Si j'incorpore les changes de e2 dans e1 ( pijul pull e2), je me retrouve avec
e1={A<-C->B}, e2={A<-C->B, D<-E}
On n'a donc pas eu à ré-effectuer la résolution par nous-même.
C'est bien ça ?
Ce que j'ai du mal à imaginer par contre, c'est un cas où le git rerere ou même le fait de rejouer le même conflit serait nécessaire ici.
Sauf peut-être... si on a commencé à jouer avec des cherry-picks entre 2 branches de release. Et je ne vois pas non plus vraiment, dans quelles situations un rebase (vu en tant que suite de cherry-picks) redemanderait de ré-appliquer les mêmes conflits.
Mais je conviens que l'approche de Pijul est élégante et moins hasardeuse.
[^] # Re: Exemples concrets?
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
J'avoue que ça reste encore un peu flou, alors j'essaye de détailler.
Afin de lever toute ambiguïté, je te propose d'utiliser la terminologie suivante (Je sais que vous y réfléchissez encore et j'ai pas mal cogité et bidouillé de mon côté ;-) :
Toute branche au sens de Pijul est appelée ensemble car ce n'est ni plus ni moins que ça - un ensemble de patchs (change) atomiques et de séquences de patch (interdépendants et ordonnés) -.
Par exemple, si on a 2 sous-ensembles dans notre dépôt:
e1={A} et e2={A, D<-E}.
Chacune de ces entités (unités de changement ou séquences) commutent entre elles. On a, de par la commutativité:
{A, D<-E} == {D<-E, A} != {E<-D, A}
(Une séquence ne commute pas entre ses propre constituants mais commute avec les autres entités).
Jusque là, j'ai juste ?
Admettons que l'on incorpore un nouveau change ( pijul pull ) B dans e1 qui entre en conflit et que l'on doive évidemment le résoudre avant de l'intégrer ce qui donne C comme dépendance. ( pijul dependencies)
Si te je suis toujours, on obtient à présent:
e1={A<-C->B}, e2={A, D<-E}
Si j'incorpore les changes de e2 dans e1 ( pijul pull e2), je me retrouve avec
e1={A<-C->B}, e2={A<-C->B, D<-E}
On n'a donc pas eu à ré-effectuer la résolution par nous-même.
C'est bien ça ?
Ce que j'ai du mal à imaginer par contre, c'est un cas où le git rerere ou même le fait de rejouer le même conflit serait nécessaire ici.
Sauf peut-être... si on a commencé à jouer avec des cherry-picks entre 2 branches de release. Et je ne vois pas non plus vraiment, dans quelles situations un rebase (vu en tant que suite de cherry-picks) redemanderait de ré-appliquer les mêmes conflits.
Mais je conviens que l'approche de Pijul est élégante et moins hasardeuse.