Désolé je ne saisis toujours pas. Lorsque tu parles de commuter des patchs en //, tu veux dire dans le cas d'un rebase ?
Peut-être y a-t-il un problème de vocabulaire. Quand je dis "les patchs commutent", ça ne veut pas dire qu'on doit les faire commuter manuellement, ça veut dire qu'on peut toujours les appliquer dans le désordre, et que ça n'a aucune importance, dans 100% des cas.
(les mots en gras sont importants).
Avec git, on obtient aussi le même résultat. Je ne vois toujours pas l'intérêt de cette commutation.
Même sur ce petit exemple simplifié, ce n'est déjà pas clair, parce que le rebase change l'identité des commits, HEAD peut être différent chez Alice et chez Bob, et la suite du travail génèrera de faux conflits qu'il faudra résoudre manuellement. Par contre, je suis d'accord que l'effet immédiat sur le texte, dans les cas où les heuristiques de Git arrivent à se rendre compte que les commits commutent (ça a de grandes chances d'être le cas ici, je n'ai pas essayé), est le même.
Dans le cas général, c'est encore plus faux, par exemple s'il y a des conflits, ça ne fait pas forcément la même chose (ne serait-ce que parce qu'il faut résoudre le conflit pour que Git accepte de rebaser).
Dans les deux cas, ça demande une opération manuelle consciente, alors que Pijul le fait automatiquement dans 100% des cas. Même si je suis d'accord que git rebase n'est pas très dur dans les cas simples, il faut quand même prendre le temps de réfléchir aux conséquences, à la disposition des branches, à ce qu'on veut faire après, etc. avant de le faire, ce qui peut engendrer (en tout cas dans mon propre travail) des pertes de temps d'autant plus importantes que la deadline est proche et que le vrai objectif du projet (qui n'est que rarement d'utiliser Git) est difficile.
[^] # Re: Patchez moi !
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 5.
Peut-être y a-t-il un problème de vocabulaire. Quand je dis "les patchs commutent", ça ne veut pas dire qu'on doit les faire commuter manuellement, ça veut dire qu'on peut toujours les appliquer dans le désordre, et que ça n'a aucune importance, dans 100% des cas.
(les mots en gras sont importants).
Même sur ce petit exemple simplifié, ce n'est déjà pas clair, parce que le rebase change l'identité des commits,
HEADpeut être différent chez Alice et chez Bob, et la suite du travail génèrera de faux conflits qu'il faudra résoudre manuellement. Par contre, je suis d'accord que l'effet immédiat sur le texte, dans les cas où les heuristiques de Git arrivent à se rendre compte que les commits commutent (ça a de grandes chances d'être le cas ici, je n'ai pas essayé), est le même.Dans le cas général, c'est encore plus faux, par exemple s'il y a des conflits, ça ne fait pas forcément la même chose (ne serait-ce que parce qu'il faut résoudre le conflit pour que Git accepte de rebaser).
Dans les deux cas, ça demande une opération manuelle consciente, alors que Pijul le fait automatiquement dans 100% des cas. Même si je suis d'accord que
git rebasen'est pas très dur dans les cas simples, il faut quand même prendre le temps de réfléchir aux conséquences, à la disposition des branches, à ce qu'on veut faire après, etc. avant de le faire, ce qui peut engendrer (en tout cas dans mon propre travail) des pertes de temps d'autant plus importantes que la deadline est proche et que le vrai objectif du projet (qui n'est que rarement d'utiliser Git) est difficile.