Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds »
Des gens ont effectivement dit ça, mais en pratique plein de projets et d'entreprises sont encore sous CVS.
Torvalds lui-même le considère comme très imparfait, même si je suis d'accord que Git a connu un développement impressionnant (j'ai l'impression que c'est en très grande partie grâce à GitHub).
Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.
Cependant, je suis convaincu que ça en vaut la peine.
Je n'ai aucun problème à apprendre des trucs. Dans la vie, je suis chercheur : mon métier est d'apprendre des trucs qui n'ont pas de courbe d'apprentissage connue.
Pour des outils standards et connus, je n'ai pas non plus de problème, mais seulement quand ça vaut le coup.
Si tu as besoin d'exemples, regarde les langages qu'on utilise (Rust, Nix) et les dépendances de Pijul qu'on a dû écrire (Sanakirja, Thrussh).
Par exemple, il est beaucoup plus difficile d'apprendre le monocycle que le vélo. Si l'objectif est de se déplacer, ton commentaire ressemble à "oui mais le monocycle est plus difficile à apprendre, donc il est forcément plus efficace".
Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose...
C'est vrai dans plein de cas. Dans le nôtre, c'est plutôt l'inverse qui est vrai : Pijul est capable de reproduire tous les workflows possibles de Git, et peut faire des choses largement plus puissantes, tout en restant simple.
Ce genre de trucs a déjà existé avant en informatique : dans les années 70, plein de gens adoraient la courbe d'apprentissage de leur langage préféré (et étaient très créatifs pour inventer de nouveaux langages obscures chaque semaine). Et à un moment, tout le monde s'est rendu compte que C offrait au moins la même puissance que les autres, en beaucoup plus souple et facile.
soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration
Ce n'est pas du tout le principal problème de ces gros utilisateurs. Leur principale préoccupation est bien le passage à l'échelle : Git devient très lent sur les très gros dépôts, parce qu'il a besoin de tout l'historique de tout pour fonctionner.
Et ces gros industriels veulent de très gros dépôts parce qu'ils ont plein de projets interdépendants compliqués à compiler.
(même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique)
Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.
[^] # 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é à 4.
Des gens ont effectivement dit ça, mais en pratique plein de projets et d'entreprises sont encore sous CVS.
Torvalds lui-même le considère comme très imparfait, même si je suis d'accord que Git a connu un développement impressionnant (j'ai l'impression que c'est en très grande partie grâce à GitHub).
Je n'ai aucun problème à apprendre des trucs. Dans la vie, je suis chercheur : mon métier est d'apprendre des trucs qui n'ont pas de courbe d'apprentissage connue.
Pour des outils standards et connus, je n'ai pas non plus de problème, mais seulement quand ça vaut le coup.
Si tu as besoin d'exemples, regarde les langages qu'on utilise (Rust, Nix) et les dépendances de Pijul qu'on a dû écrire (Sanakirja, Thrussh).
Par exemple, il est beaucoup plus difficile d'apprendre le monocycle que le vélo. Si l'objectif est de se déplacer, ton commentaire ressemble à "oui mais le monocycle est plus difficile à apprendre, donc il est forcément plus efficace".
Pour les cas désespérés, il y a toujours https://git-man-page-generator.lokaltog.net/
C'est vrai dans plein de cas. Dans le nôtre, c'est plutôt l'inverse qui est vrai : Pijul est capable de reproduire tous les workflows possibles de Git, et peut faire des choses largement plus puissantes, tout en restant simple.
Ce genre de trucs a déjà existé avant en informatique : dans les années 70, plein de gens adoraient la courbe d'apprentissage de leur langage préféré (et étaient très créatifs pour inventer de nouveaux langages obscures chaque semaine). Et à un moment, tout le monde s'est rendu compte que C offrait au moins la même puissance que les autres, en beaucoup plus souple et facile.
Ce n'est pas du tout le principal problème de ces gros utilisateurs. Leur principale préoccupation est bien le passage à l'échelle : Git devient très lent sur les très gros dépôts, parce qu'il a besoin de tout l'historique de tout pour fonctionner.
Et ces gros industriels veulent de très gros dépôts parce qu'ils ont plein de projets interdépendants compliqués à compiler.
Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.