Une partie des "avantages géniaux" que tu évoques sont utiles uniquement parce qu'ils permettent de compenser les problèmes posés par le manque de principes solides dessous.
Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ? Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ? Tu restes vague et ça ne me convainc pas.
Et chaque commit a besoin de calculer un hash de tout le dépôt
Heu... WTF ? Git ne recalcule jamais de « hash de tout le dépôt » ! Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici... C'est justement ce qui fait la vitesse de git, il a juste besoin d'aller chopper les objets en relation avec le(s) commit(s) précédent(s), et que tout est hashé et donc dépend pas du tout de la complexité de ton dépôt, mais légèrement du nombre d'objets.
ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.
WTF2 ?! Git ne stock aucun diff lié à un commit : il a juste un algo de packing qui dé-duplique, mais sans aucune relation avec un commit donné. Ce dernier ne contient que des SHA1 du/des tree(s) référencé.
les relations entre ces concepts sont compliquées et floues, voire incohérentes : par exemple, les fichiers sont rebricolés à partir du contenu par des heuristiques, et les merges entre branches sont faits par 3-way merge, qui n'est pas associatif (pas associatif = des lignes ajoutées par Alice se retrouvent dans un morceau que Bob a écrit indépendamment).
Heu... oui, les « fichiers » sont effectivement juste du contenu et la liaison avec un path donné n'est pas reverse-trackée et juste trouvée par heuristique, mais c'est plutôt très clair et simple comme concept. Oui, ça fait que les copies et déplacement de fichiers avec modification sont suivis par heuristique, mais c'est très cohérent en fait : il n'existe de « vrai » lien entre deux fichiers modifiés et déplacés que dans la tête du programmeur, et vouloir tracker ça en plus du contenu va pouvoir amener à des difficultés qui font que git préfère simplement ne pas le faire. Oui, les 3-way merge ne sont pas associatifs, mais pareil, je ne sais pas si chercher absolument un sens à toute combinaison de patch ne va pas t'amener vers des problèmes simplement insolubles. Ou alors qui de toutes façons amèneront une telle complexité que personne n'en voudra.
Bref, pour quelqu'un qui dit très bien connaître git, je trouve certains de tes arguments légers. Après, je vois qu'on a une idée du design logicielle assez différente, et donc qu'on aura du mal à réconcilier nos arguments là-dessus, mais perso avec l'expérience (je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi, vu tes vidéos ;-)) je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par benoar . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 4.
Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ? Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ? Tu restes vague et ça ne me convainc pas.
Heu... WTF ? Git ne recalcule jamais de « hash de tout le dépôt » ! Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici... C'est justement ce qui fait la vitesse de git, il a juste besoin d'aller chopper les objets en relation avec le(s) commit(s) précédent(s), et que tout est hashé et donc dépend pas du tout de la complexité de ton dépôt, mais légèrement du nombre d'objets.
WTF2 ?! Git ne stock aucun diff lié à un commit : il a juste un algo de packing qui dé-duplique, mais sans aucune relation avec un commit donné. Ce dernier ne contient que des SHA1 du/des tree(s) référencé.
Heu... oui, les « fichiers » sont effectivement juste du contenu et la liaison avec un path donné n'est pas reverse-trackée et juste trouvée par heuristique, mais c'est plutôt très clair et simple comme concept. Oui, ça fait que les copies et déplacement de fichiers avec modification sont suivis par heuristique, mais c'est très cohérent en fait : il n'existe de « vrai » lien entre deux fichiers modifiés et déplacés que dans la tête du programmeur, et vouloir tracker ça en plus du contenu va pouvoir amener à des difficultés qui font que git préfère simplement ne pas le faire. Oui, les 3-way merge ne sont pas associatifs, mais pareil, je ne sais pas si chercher absolument un sens à toute combinaison de patch ne va pas t'amener vers des problèmes simplement insolubles. Ou alors qui de toutes façons amèneront une telle complexité que personne n'en voudra.
Bref, pour quelqu'un qui dit très bien connaître git, je trouve certains de tes arguments légers. Après, je vois qu'on a une idée du design logicielle assez différente, et donc qu'on aura du mal à réconcilier nos arguments là-dessus, mais perso avec l'expérience (je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi, vu tes vidéos ;-)) je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.