Posté par pmeunier .
En réponse au journal Pijul 0.11.
Évalué à 2.
Dernière modification le 06 décembre 2018 à 10:29.
Est-ce que l'objectif est de défendre Git coûte que coûte, ou de comprendre mes arguments ? Dans le doute, je vais faire comme si c'était de comprendre mon argument.
Hum... Non ? git t'oblige à avoir une copie de travail (clone), ensuite le fait de faire une branche c'est juste une bonne pratique.
C'est un peu plus qu'une bonne pratique, c'est la seule solution pour faire commuter des patchs indépendants, et le seul avantage de Git sur SVN (un gros avantage, on est d'accord). La commutation du travail est la principale intuition derrière le contrôle de versions distribué, c'est le truc que les algos de merge de Git essaient de simuler.
Tu peux très bien te retrouver avec un historique non linéaire en git, mais tu va te faire mal. C'est pas de la faute de git.
100% d'accord, mais je maintiens que ce n'est pas pour une bonne raison, c'est juste parce que Git ne me laisse pas parler de patchs sans avoir à rebaser (un peu comme à l'époque où SVN ne me laissait pas parler de commit sans avoir à merger).
Comprendre un historique non linéaire est une plaie. Trouver une erreur dans une jungle de patch est à des magnitudes plus compliquées qu'avec un log linéaire.
Je suis partiellement d'accord, et c'est d'ailleurs pour ça que Pijul a les deux. Dans Pijul, une branche a un historique linéaire et un ensemble de patchs.
Ça permet d'enlever des patchs presque n'importe où dans l'historique sans avoir à rebaser. Et deux historiques qui contiennent les mêmes patchs, même pas forcément dans le même ordre, produisent toujours les mêmes fichiers (ce n'est pas toujours le cas dans Git, même quand les commits ont été mis dans le même ordre à coups de rebase).
Pour trouver une erreur, j'imagine que tu fais référence à git bisect. C'est carrémment possible dans Pijul, même si on ne l'a pas encore implémenté, et on peut même isoler des ensembles de patchs bien plus finement que dans Git.
Merger plus de 2 fichiers est aussi bien plus compliqué, déjà qu'en merger 2 est casse gueule.
C'est vrai quand on merge avec une "heuristique qui marche souvent". Quand on a un algo de merge qui vérifie certains axiomes pratiques, et où tout est réversible, c'est plus facile. Bien entendu, travailler ensemble et se mettre d'accord c'est dur dans la vraie vie, donc fusionner des changements l'est aussi. Mais au moins, Pijul ne le rend pas plus dur que la vraie vie en introduisant des sources d'erreurs techniques.
C'est vraiment décidable d'avoir A(B(C())) == A(C(B())) ?
Dans Pijul la commutation BC=CB est décidable, parce que des patchs qui ne commutent pas se référencent toujours explicitement (ou via une chaîne de dépendances), donc des patchs créés indépendamment commutent toujours (donc c'est décidable). À ce sujet, dans Darcs, la commutation est décidable sans conflits, et avec des conflits non-triviaux je ne comprends pas trop ce qu'il fait.
Mais là, c'est plutôt A(BC) == (AB)C. Et c'est décidable si A, B et C sont des patchs produits par Pijul, puisque c'est toujours le cas (une machine de Turing qui voudrait le décider s'arrêterait tout de suite sans regarder les patchs, et répondrait "oui").
Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer.
Et d'ailleurs, Pijul peut même améliorer la qualité de l'historique par rapport à Git ! Vu que Pijul n'a pas besoin de rebaser des changements pour les appliquer sur une autre branche, on peut retracer l'historique des changements, qui serait complètement perdus sinon. C'est bien pratique quand on a une branche instable et une branche stable, par exemple, et qu'on fait passer les correctifs de bugs de la branche instable à la branche stable.
Ça, en Git, ce serait un cauchemar, géré à coups de rebases et autres "rerere", au prix de longues et stressantes heures de travail qui auraient peut-être été mieux investies à réfléchir à l'algo ou à écrire du code.
Surtout que je ne vois pas la contrainte que cela pose. Éventuellement tu peux me parler du fait que ça contraint celui qui veux fusionner son code à faire en sorte qu'il fusionne correctement.
Clairement, quand on travaille tout seul sur une histoire linéaire, ou qu'on s'organise suffisamment bien pour découper le projet à l'avance sans jamais changer radicalement d'organisation, Git ne pose aucune contrainte.
Mais dès qu'on bosse sur un projet un peu moins bien défini, ou qu'on veut revenir en arrière de façon un peu non-triviale (annuler le patch d'avant-hier, mais pas celui d'hier), ou fusionner des branches temporairement, ou "cueillir des cerises", ça devient super contraint.
Attention, je n'ai pas dit impossible, Git permet bien de faire tout ce qu'on veut. J'ai juste dit "contraint", ce qui implique que ça engendre des coûts de maintenance importants dans certains projets.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par pmeunier . En réponse au journal Pijul 0.11. Évalué à 2. Dernière modification le 06 décembre 2018 à 10:29.
Est-ce que l'objectif est de défendre Git coûte que coûte, ou de comprendre mes arguments ? Dans le doute, je vais faire comme si c'était de comprendre mon argument.
C'est un peu plus qu'une bonne pratique, c'est la seule solution pour faire commuter des patchs indépendants, et le seul avantage de Git sur SVN (un gros avantage, on est d'accord). La commutation du travail est la principale intuition derrière le contrôle de versions distribué, c'est le truc que les algos de merge de Git essaient de simuler.
100% d'accord, mais je maintiens que ce n'est pas pour une bonne raison, c'est juste parce que Git ne me laisse pas parler de patchs sans avoir à rebaser (un peu comme à l'époque où SVN ne me laissait pas parler de commit sans avoir à merger).
Je suis partiellement d'accord, et c'est d'ailleurs pour ça que Pijul a les deux. Dans Pijul, une branche a un historique linéaire et un ensemble de patchs.
Ça permet d'enlever des patchs presque n'importe où dans l'historique sans avoir à rebaser. Et deux historiques qui contiennent les mêmes patchs, même pas forcément dans le même ordre, produisent toujours les mêmes fichiers (ce n'est pas toujours le cas dans Git, même quand les commits ont été mis dans le même ordre à coups de rebase).
Pour trouver une erreur, j'imagine que tu fais référence à
git bisect. C'est carrémment possible dans Pijul, même si on ne l'a pas encore implémenté, et on peut même isoler des ensembles de patchs bien plus finement que dans Git.C'est vrai quand on merge avec une "heuristique qui marche souvent". Quand on a un algo de merge qui vérifie certains axiomes pratiques, et où tout est réversible, c'est plus facile. Bien entendu, travailler ensemble et se mettre d'accord c'est dur dans la vraie vie, donc fusionner des changements l'est aussi. Mais au moins, Pijul ne le rend pas plus dur que la vraie vie en introduisant des sources d'erreurs techniques.
Dans Pijul la commutation BC=CB est décidable, parce que des patchs qui ne commutent pas se référencent toujours explicitement (ou via une chaîne de dépendances), donc des patchs créés indépendamment commutent toujours (donc c'est décidable). À ce sujet, dans Darcs, la commutation est décidable sans conflits, et avec des conflits non-triviaux je ne comprends pas trop ce qu'il fait.
Mais là, c'est plutôt A(BC) == (AB)C. Et c'est décidable si A, B et C sont des patchs produits par Pijul, puisque c'est toujours le cas (une machine de Turing qui voudrait le décider s'arrêterait tout de suite sans regarder les patchs, et répondrait "oui").
Et d'ailleurs, Pijul peut même améliorer la qualité de l'historique par rapport à Git ! Vu que Pijul n'a pas besoin de rebaser des changements pour les appliquer sur une autre branche, on peut retracer l'historique des changements, qui serait complètement perdus sinon. C'est bien pratique quand on a une branche instable et une branche stable, par exemple, et qu'on fait passer les correctifs de bugs de la branche instable à la branche stable.
Ça, en Git, ce serait un cauchemar, géré à coups de rebases et autres "rerere", au prix de longues et stressantes heures de travail qui auraient peut-être été mieux investies à réfléchir à l'algo ou à écrire du code.
Clairement, quand on travaille tout seul sur une histoire linéaire, ou qu'on s'organise suffisamment bien pour découper le projet à l'avance sans jamais changer radicalement d'organisation, Git ne pose aucune contrainte.
Mais dès qu'on bosse sur un projet un peu moins bien défini, ou qu'on veut revenir en arrière de façon un peu non-triviale (annuler le patch d'avant-hier, mais pas celui d'hier), ou fusionner des branches temporairement, ou "cueillir des cerises", ça devient super contraint.
Attention, je n'ai pas dit impossible, Git permet bien de faire tout ce qu'on veut. J'ai juste dit "contraint", ce qui implique que ça engendre des coûts de maintenance importants dans certains projets.