Bien sur, mais personelle;ent des qu'il y a un merge, avec ou sans conflit, je passe temps qu'il faut pour verifier, et pour ca ce que cet outil propose n'apportera rien de concret sur ce point.
Et mes propos sont vraiment lié au sentiment que l'article et la discussion qui s'en suit me laisse: l'impression de vouloir résoudre un probleme qui est souvent marginal (et qu'on peux déjà résoudre avec les outils existant) et qui de toute maniere ne resouds pas le probleme principale qui est la cohérence du code/texte produit au final, et pour ca il faudrait un VSC qui comprends le langage qu'il gère, et qui est plutôt utopiste.
Mon probleme est ici, est-ce que le probleme qu'on cherche a résoudre est vraiment pertinent? Et surtout vaut-il l'effort mis a le résoudre?
Si c'est pour améliorer LE cas de "revert" qui arrive une fois tous les 36 du mois mais complexifie certaines autres taches et/ou les rends plus lentes et/ou plus complexe a comprendre, est-ce que ca vaut le coup? Je ne suis pas sur.
Et l'histoire que Git utilise des snapshort vs cet outils que des diff est pour mois un detail au meme titre de comment est stocké le depot.
L'un et l'autre sont interchangeable, on peu facilement passer de l'un a l'autre.
Par exemple le coté "associatif" des "patchs" apporte quoi concretement? Personne n'a donné d'exemple reel qui demande l'utilisation de ce genre de fonctionalitée. Et perso l'explication "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." je compredsn la meme chose pour les deux, on applique A, puis B, puis C, et on obtiens le meme resultat quand on applie A puis B puis C.
Quand a la "gestion des conflits en interne" je ne suis pas sur que ca soit une idee merveilleuse, car il y a tout un tas de cas ou tu va resoudre un conflit differement suivant ce qui se passe sur la dépot.
Et des propos comme ca sont personellement déconnecté de la realitée:
Mais comme deux ensembles de patchs identiques produisent toujours le même résultat, même dans des ordres différents, l'ordre a largement moins d'importance que dans Git.
L'ordre a de l'importance, deja d'une part du point de vue du versionning a proprement parler. la version 1.0 a du code qui a été écrit dans un certains ordre, ensuite viens la 1.1, la 1.2, ... 2.0, ... Du code ecrit pour la 3.0 n'a aucune raison d'apparailtre dans l'historique avant la publication de la 1.0, meme si au final apres avoir appliqué tous les patches tu as exactement le meme code dans la tete de branche.
L'ordre des commit/patch a un sens. Pour prendre un exemple par l'absurde: ce n'est pas parceque tu obtiens le meme texte au final que tu peux lire les chapitres d'un livre dans l'ordre que tu veux