À moins que j'ai vraiment loupé un truc, seule l'attitude de git, s'arrêter et te dire t'es gentil tu corriges tes conneries est valide.
Pijul fait bien entendu la même chose.
Je voudrais juste rajouter que "appliquer les patchs successivement" a un sens, mais Pijul garantit que les applique dans n'importe quel ordre fait la même chose, ce qui permet de laisser les deux développeurs faire un pull de l'autre, et d'aboutir à exactement le même résultat :
Le développeur cool pull un patch qui ajoute des lignes dans un contexte (les lignes autour) qu'il a supprimé, c'est un conflit.
Le développeur pas cool pull un patch P qui supprime des lignes, mais ces lignes supprimées ont du contexte qui ne fait pas partie des dépendances de P. C'est le même conflit.
L'attitude de Git dans ce cas :
dépend du contenu des lignes. Parfois il ne verra pas le conflit, et ajoutera la nouvelle ligne à un autre endroit du code.
dépend de l'ordre dans lequel ces patchs ont été appliqués.
Ce n'est pas complètement raisonnable, en particulier sur des codes plus gros qu'une fonction de trois lignes qui fait un truc simple.
Ce qui est encore moins raisonnable, c'est que Git peut en plus, dans pas mal de cas, indiquer un conflit alors qu'il n'y en a pas, simplement parce que le manuel de bonnes pratiques a dit de faire un rebase il y a trois mois. L'intention du manuel était bonne : il s'agissait juste d'essayer de simuler la commutation de patchs. Mais ça n'a pas trop marché, et maintenant il faut relire un code déjà testé et relu quinze fois auparavant, pour s'assurer encore une fois que tout va bien, alors que ce n'est pas forcément sur ce morceau-là du projet qu'on voudrait travailler maintenant.
Relire du code est absolument essentiel, on est d'accord, mais on peut aussi supposer que les participants au projet ont un temps de travail fini, et des priorités de relecture et de tests décidés par autre chose que par Git. Dans ce cas, c'est une perte de temps.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par pmeunier . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 10.
Pijul fait bien entendu la même chose.
Je voudrais juste rajouter que "appliquer les patchs successivement" a un sens, mais Pijul garantit que les applique dans n'importe quel ordre fait la même chose, ce qui permet de laisser les deux développeurs faire un pull de l'autre, et d'aboutir à exactement le même résultat :
L'attitude de Git dans ce cas :
Ce n'est pas complètement raisonnable, en particulier sur des codes plus gros qu'une fonction de trois lignes qui fait un truc simple.
Ce qui est encore moins raisonnable, c'est que Git peut en plus, dans pas mal de cas, indiquer un conflit alors qu'il n'y en a pas, simplement parce que le manuel de bonnes pratiques a dit de faire un rebase il y a trois mois. L'intention du manuel était bonne : il s'agissait juste d'essayer de simuler la commutation de patchs. Mais ça n'a pas trop marché, et maintenant il faut relire un code déjà testé et relu quinze fois auparavant, pour s'assurer encore une fois que tout va bien, alors que ce n'est pas forcément sur ce morceau-là du projet qu'on voudrait travailler maintenant.
Relire du code est absolument essentiel, on est d'accord, mais on peut aussi supposer que les participants au projet ont un temps de travail fini, et des priorités de relecture et de tests décidés par autre chose que par Git. Dans ce cas, c'est une perte de temps.