La seule chose que tu as fait c'est nier un problème que même Linus ne nie pas et auquel il propose une solution pour contourner les limites de git
Je me cite:
Oui, c'est là qu'on atteint les limites de Git. Essentiellement, l'unique algorithme disponible (contrairement à ce qu'on nous vend) est le 3 way merge et dans certaines situations, déterminer le contributeur de base peut conduire à des cas tordus. Parfois, se baser dessus n'incombe pas le comportement attendu.
En revanche ile est clair que les méthodes de projets modernes (agiles) atténuent grandement les désagréments liés à ces problématiques de fusions.
Que ce soit le Continuous Delivery, Scrum ou autres. Elles s'appuient sur la création de branches par fonctionnalité (feature branches) et l'intégration via des pull requests, ce qui limite leur durée de vie dans le temps.
Hormis les considérations GCL (pardon, de versionning) elles apportent d'autres avantages (A/B testing, ...).
Bref, dans la vraie vie, ces scénarios que vous décrivez n'existent qu'à la marge et ne justifient pas un changement d'outil.
Mais je ne doute pas que Pijul a d'autres arguments et nous démontrera ses vertus. Il a pour lui de beaux arguments (Rust, une UI épurée, la jeunesse, une théorie que j'aimerais voir concrètement appliquée, ...)
[^] # Re: Soit j'ai rien compris soit...
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é à 4.
Je me cite:
En revanche ile est clair que les méthodes de projets modernes (agiles) atténuent grandement les désagréments liés à ces problématiques de fusions.
Que ce soit le Continuous Delivery, Scrum ou autres. Elles s'appuient sur la création de branches par fonctionnalité (feature branches) et l'intégration via des pull requests, ce qui limite leur durée de vie dans le temps.
Certains protagonistes vont même plus loin en prônant le "trunk dev" (une branche unique) pour encourager l'intégration continue (au sens propre), principe fondateur de l'agilité.
https://martinfowler.com/bliki/FeatureBranch.html
Ils proposent d'autres techniques pour aborder les developpement // comme
https://www.martinfowler.com/articles/feature-toggles.html
https://martinfowler.com/bliki/BranchByAbstraction.html
Hormis les considérations GCL (pardon, de versionning) elles apportent d'autres avantages (A/B testing, ...).
Bref, dans la vraie vie, ces scénarios que vous décrivez n'existent qu'à la marge et ne justifient pas un changement d'outil.
Mais je ne doute pas que Pijul a d'autres arguments et nous démontrera ses vertus. Il a pour lui de beaux arguments (Rust, une UI épurée, la jeunesse, une théorie que j'aimerais voir concrètement appliquée, ...)
A suivre