Posté par barmic .
En réponse au journal Pijul 0.11.
Évalué à 2.
Dernière modification le 05 décembre 2018 à 18:50.
Merci pour ton commentaire :)
Git oblige ses utilisateurs à forker (brancher) les dépôts alors qu'ils voudraient en réalité envoyer un patch pour faire avancer le projet. Cette différence, qui, je te l'accorde, paraît évidente après des années de Git, n'a rien de naturel. Et d'ailleurs, git log -p affiche un patch (des changements), pas un commit (une version) !
Hum... Non ? git t'oblige à avoir une copie de travail (clone), ensuite le fait de faire une branche c'est juste une bonne pratique. D'ailleurs c'est une vue de l'esprit, ce que tu fais c'est donner un nom à ta partie de travaille.
C'est pas une contrainte folle.
Git séquentialise tout. Si je veux combiner des changements depuis plusieurs branches librement, il faut que je choisisse un ordre, même si les commits ont été produits en même temps. Ça encore, ça n'a rien de naturel ! D'autant plus que comme Git n'a pas de vrai algo de merge, l'ordre que je choisis ne fera pas forcément la même chose, je ne verrai pas les mêmes conflits, et même sans conflits, parfois pas les mêmes fichiers !
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. 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. Merger plus de 2 fichiers est aussi bien plus compliqué, déjà qu'en merger 2 est casse gueule.
Le deuxième problème de Git est l'absence d'associativité des changements. Si je git commit A, puis que je git pull B et C en même temps, ça ne fait pas toujours la même chose que si je commit A, puis que je git pull B, puis git pull C. Ça, c'est parce que l'algo de merge de Git est un algo d'optimisation que a parfois plusieurs solutions, auquel cas il en choisit une arbitrairement (sans même en avertir l'utilisateur). Et ça arrive même en l'absence de conflits.
C'est vraiment décidable d'avoir A(B(C())) == A(C(B())) ?
La réponse est purement technique, c'est parce que gérer des patchs, ça rend les changements asynchrones, et qu'on ne comprend pas grand chose à l'asynchronisme, en pratique comme en théorie.
Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer. 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.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . En réponse au journal Pijul 0.11. Évalué à 2. Dernière modification le 05 décembre 2018 à 18:50.
Merci pour ton commentaire :)
Hum... Non ? git t'oblige à avoir une copie de travail (clone), ensuite le fait de faire une branche c'est juste une bonne pratique. D'ailleurs c'est une vue de l'esprit, ce que tu fais c'est donner un nom à ta partie de travaille.
C'est pas une contrainte folle.
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. 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. Merger plus de 2 fichiers est aussi bien plus compliqué, déjà qu'en merger 2 est casse gueule.
C'est vraiment décidable d'avoir A(B(C())) == A(C(B())) ?
Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer. 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.