Git ne gère pas vraiment ça dans 100% des cas, mais tu as raison, on voit qu'il aimerait bien simuler la commutation des patchs :
Dans le cas des conflits, Git rerere ne se souvient pas vraiment du conflit, parce qu'il n'y a pas de représentation des conflits propre dans Git. Un conflit, c'est un merge qui n'a pas marché, il faut le résoudre. Git rerere est une heuristique pour essayer de se rappeler comment on a résolu la première fois, et ça marche dans plein de cas. Mais même si Git a des heuristiques qui marchent sans doute bien sur les exemples simples, il lui manquera de toute façon des informations.
La commutation ne sert pas qu'à résoudre des conflits, ça sert aussi à éviter d'avoir à organiser son travail à l'avance très précisément. Il y a des cas (soit très simplifiés, soit très rigoureux) où ce n'est pas nécessaire. Dans tous les projets où je suis impliqué, c'est crucial. La seule exception (dans mon cas) est peut-être nixpkgs, mais même là, j'aimerais bien pouvoir composer mes versions comme je veux, sans avoir à perdre des heures dans des merges et des rebases que je vais devoir de toute façon défaire au bout d'un moment quand mes PR seront acceptées.
[^] # Re: Soit j'ai rien compris soit...
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3.
Git ne gère pas vraiment ça dans 100% des cas, mais tu as raison, on voit qu'il aimerait bien simuler la commutation des patchs :
Dans le cas des conflits, Git rerere ne se souvient pas vraiment du conflit, parce qu'il n'y a pas de représentation des conflits propre dans Git. Un conflit, c'est un merge qui n'a pas marché, il faut le résoudre.
Git rerereest une heuristique pour essayer de se rappeler comment on a résolu la première fois, et ça marche dans plein de cas. Mais même si Git a des heuristiques qui marchent sans doute bien sur les exemples simples, il lui manquera de toute façon des informations.La commutation ne sert pas qu'à résoudre des conflits, ça sert aussi à éviter d'avoir à organiser son travail à l'avance très précisément. Il y a des cas (soit très simplifiés, soit très rigoureux) où ce n'est pas nécessaire. Dans tous les projets où je suis impliqué, c'est crucial. La seule exception (dans mon cas) est peut-être nixpkgs, mais même là, j'aimerais bien pouvoir composer mes versions comme je veux, sans avoir à perdre des heures dans des merges et des rebases que je vais devoir de toute façon défaire au bout d'un moment quand mes PR seront acceptées.