tu pourrais passer à côté des choses géniales que tu ne remarques même pas.
Encore une fois, si on a commencé Pijul, c'est qu'on connaissait suffisamment bien Git pour en être insatisfaits.
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.
Mais il y a aussi plein de trucs absolument géniaux dans Git ! Je n'ai jamais dit le contraite ! À commencer par la vitesse, designer des algos avec le potentiel pour le battre en vitesse a été vraiment intéressant.
Option « --depth » de git-clone, et pour aller plus loin voir le fonctionnement du fichier « shadow » dans le .git
Suggestion : suppose que les ingénieurs de Google et Facebook (et plus généralement les gens avec qui tu parles, dont moi) connaissent ces options quand ils disent ce type de trucs.
Les shallow clones améliorent un peu ce problème dans certains cas, en particulier ils permettent de compiler le projet, mais pas forcément de "travailler" sur le projet, comme par exemple de fusionner des commits qui ont divergé depuis plus longtemps que la profondeur.
Et chaque commit a besoin de calculer un hash de tout le dépôt, même si ce n'est que pour un seul fichier (j'imagine que ce n'est pas le principal souci, même dans une grosse instance).
C'est drôle que tu prennes l'exemple du C, parce que justement il a une courbe d'apprentissage un peu rude quand même, il n'est pas parfait, et j'aurais donc fait le parallèle avec git.
Je n'ai pas pris C au hasard. Encore une fois, la courbe d'apprentissage n'est pas toujours égale à la puissance de l'outil.
C est certes difficile à maîtriser, mais il est basé sur un petit nombre de concepts simples (fonctions, variables, pointeurs, préprocesseur) et orthogonaux, qu'on peut expliquer facilement, ce qui n'était pas le cas des langages d'avant.
Git a un point commun avec C, le petit nombre de concepts (branches, commits, trees).
Par contre, il est très différent de C sur deux points :
ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.
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).
[^] # 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é à 7.
Encore une fois, si on a commencé Pijul, c'est qu'on connaissait suffisamment bien Git pour en être insatisfaits.
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.
Mais il y a aussi plein de trucs absolument géniaux dans Git ! Je n'ai jamais dit le contraite ! À commencer par la vitesse, designer des algos avec le potentiel pour le battre en vitesse a été vraiment intéressant.
Suggestion : suppose que les ingénieurs de Google et Facebook (et plus généralement les gens avec qui tu parles, dont moi) connaissent ces options quand ils disent ce type de trucs.
Les shallow clones améliorent un peu ce problème dans certains cas, en particulier ils permettent de compiler le projet, mais pas forcément de "travailler" sur le projet, comme par exemple de fusionner des commits qui ont divergé depuis plus longtemps que la profondeur.
Et chaque commit a besoin de calculer un hash de tout le dépôt, même si ce n'est que pour un seul fichier (j'imagine que ce n'est pas le principal souci, même dans une grosse instance).
Je n'ai pas pris C au hasard. Encore une fois, la courbe d'apprentissage n'est pas toujours égale à la puissance de l'outil.
C est certes difficile à maîtriser, mais il est basé sur un petit nombre de concepts simples (fonctions, variables, pointeurs, préprocesseur) et orthogonaux, qu'on peut expliquer facilement, ce qui n'était pas le cas des langages d'avant.
Git a un point commun avec C, le petit nombre de concepts (branches, commits, trees).
Par contre, il est très différent de C sur deux points :
ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.
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).