Git a 20 ans : questions et réponses avec Linus Torvalds
Linus Torvalds célèbre le 20e anniversaire de Git. Est-il plus célèbre que Linux ?
Git a 20 ans : questions et réponses avec Linus Torvalds
Pour célébrer les vingt ans de Git, Linus Torvalds s'est livré à une foire aux questions pour discuter de la façon dont il a changé à jamais le développement de logiciels. Pour rappel, Linus Torvalds est un ingénieur logiciel finlandais, créateur et développeur principal du noyau Linux. Il a également créé le système de contrôle de version distribué Git.
Il y a exactement vingt ans, le 7 avril 2005, Linus Torvalds a effectué la toute première validation du système de contrôle de version Git. Torvalds a écrit Git en seulement 10 jours après que les développeurs du noyau Linux aient perdu l'accès à leur outil propriétaire, BitKeeper, en raison de désaccords sur les licences. En fait, lors de ce premier commit, il avait écrit suffisamment de Git pour utiliser Git pour faire le commit !
La conception non conventionnelle et décentralisée de Git, aujourd'hui omniprésente et apparemment évidente, était révolutionnaire à l'époque et a modifié la manière dont les équipes logicielles collaborent et développent.
La vidéo suivante montre l'interview de Linus Torvalds où il parle des premiers jours de Git, revient sur les principales décisions de conception à l'origine du succès durable de Git et discute de la façon dont il a changé à jamais le développement logiciel. La suite de l'article est la transcription de la vidéo.
Taylor Blau : Cela fait 20 ans, presque à l'heure près, que Git a été suffisamment auto-hébergé pour écrire son premier commit. Vous attendiez-vous à être assis ici 20 ans plus tard, à l'utiliser encore et à en parler ?
Linus Torvalds : Toujours en train de l'utiliser, oui. Peut-être pas en train d'en parler. Je veux dire que cela a été l'une des grandes surprises, à savoir à quel point il s'est imposé dans le monde du SCM. J'y voyais une solution à mes problèmes, et je pensais évidemment qu'il était supérieur. Même il y a 20 ans jour pour jour, je pensais que la première version, qui était assez brute - pour être honnête, même cette version était supérieure à CVS.
Mais en même temps, j'avais vu CVS s'accrocher au marché - SVN est apparu, mais c'est juste CVS sous une autre forme, n'est-ce pas - pendant de nombreuses décennies. Je me suis donc dit : « D'accord, ce marché est très collant. Je ne peux pas utiliser CVS parce que je le déteste passionnément, alors je vais faire mon propre truc. Je ne pouvais plus utiliser BitKeeper, évidemment. Alors je me suis dit, ok, je vais faire quelque chose qui marche pour moi, et je ne me préoccuperai pas des autres. Et cela s'est vraiment vu au cours des premiers mois et des premières années - les gens se plaignaient que c'était un peu difficile à utiliser, pas assez intuitif. Puis il s'est passé quelque chose, comme si on avait appuyé sur un bouton.
Je vais faire quelque chose qui marche pour moi, et je ne me préoccuperai pas des autres.
Taylor Blau : Vous avez parlé de BitKeeper. Nous pourrions peut-être en parler.
Linus Torvalds : Bien sûr.
Taylor Blau : Vous avez écrit la version initiale de Git en une dizaine de jours pour remplacer le noyau.
Linus Torvalds : Oui et non. Il a fallu moins de dix jours pour que je puisse l'utiliser pour le noyau, oui. Mais pour être juste, tout le processus a commencé en décembre ou novembre de l'année précédente, donc en 2004.
Ce qui s'est passé, c'est que BitKeeper avait toujours assez bien fonctionné pour moi. Il n'était pas parfait, mais il était à des années-lumière de tout ce que j'avais essayé. Mais BitKeeper dans la communauté du noyau a toujours été très mal accueilli par la communauté parce qu'il était commercial. Il était gratuit pour une utilisation open source parce que Larry McVoy, que je connaissais, aimait vraiment l'open source. Je veux dire qu'en même temps, il en faisait un business et il voulait vendre BitKeeper à de grandes entreprises. Le fait que BitKeeper ne soit pas open source et qu'il soit utilisé pour l'un des plus grands projets open source était un point de friction pour beaucoup de gens. Et c'était aussi le cas pour moi.
Dans une certaine mesure, je voulais vraiment utiliser l'open source, mais en même temps, je suis très pragmatique et il n'y avait rien d'open source qui était, même de loin, assez bon. J'espérais donc que quelque chose de mieux se présenterait. Mais ce qui est arrivé, c'est que Tridge, en Australie, a fait de la rétro-ingénierie sur BitKeeper, ce qui n'était pas si difficile, car BitKeeper était en fait une bonne enveloppe autour de SCCS, qui remonte aux années 60. SCCS est presque pire que CVS.
Mais c'était explicitement contre les règles de la licence de BitKeeper. BitKeeper disait : vous pouvez l'utiliser pour l'open source, mais vous ne pouvez pas faire d'ingénierie inverse. Et vous ne pouvez pas essayer de cloner BitKeeper. Et cela a posé d'énormes problèmes. Et tout cela se passait en privé, donc je parlais à Larry et j'envoyais des courriels à Tridge et nous essayions de trouver une solution, mais Tridge et Larry étaient vraiment aux antipodes l'un de l'autre et il n'y avait aucune solution qui se dessinait.
Lorsque j'ai commencé à écrire Git, cela faisait quatre mois que je réfléchissais à ce problème, à ce qui fonctionnait pour moi et à la question suivante : « Comment puis-je faire quelque chose qui soit encore mieux que BitKeeper, mais qui ne le fasse pas comme BitKeeper ? Je ne voulais pas me retrouver dans la situation où Larry me dirait : « Hé, tu as fait la seule chose que tu n'étais pas censé faire. »
Donc oui, la partie écriture a duré peut-être 10 jours jusqu'à ce que je commence à utiliser Git pour le noyau, mais il y a eu beaucoup de réflexion sur ce que les idées devraient être....comment faire quelque chose qui fait encore mieux que BitKeeper, mais qui ne le fait pas de la même manière que BitKeeper.
Taylor Blau : Je voudrais parler de ces deux choses. Nous pouvons commencer par cette période de 10 jours. Si j'ai bien compris, vous avez pris cette période pour vous éloigner du noyau et vous vous êtes surtout concentré sur Git de manière isolée. Comment s'est déroulée la transition entre le travail sur Git et le noyau ?
Linus Torvalds : Eh bien, comme il ne s'agissait que de deux semaines, c'est ce qui s'est passé. En fait, ce n'était pas très important. J'avais déjà fait ce genre de choses pour - au cours des 35 dernières années, j'ai été en vacances deux ou trois fois, c'est vrai, pas très souvent. Mais je me suis déjà éloigné du noyau pendant deux semaines d'affilée.
Et c'était assez intéressant parce que l'une de mes réactions a été de voir à quel point il est plus facile de programmer dans l'espace utilisateur. Il y a tellement moins de choses dont il faut se préoccuper. Vous n'avez pas à vous soucier des allocations de mémoire. Vous n'avez pas à vous soucier de beaucoup de choses. Et le débogage est tellement plus facile quand vous avez toute cette infrastructure que vous écrivez quand vous faites un noyau.
En fait, c'était un peu - je ne dirais pas relaxant, mais c'était amusant de faire quelque chose dans l'espace utilisateur où j'avais un objectif assez clair de ce que je voulais. Je veux dire, un objectif clair dans le sens où je connaissais la direction. Je ne connaissais pas les détails.
Taylor Blau : L'une des choses que je trouve intéressantes à propos de Git, surtout 20 ans plus tard, c'est que le modèle de développement qu'il encourage me semble si simple qu'il est presque évident à ce stade. Mais je ne dis pas cela comme un terme réducteur. Je pense qu'il y a eu beaucoup de réflexion pour distiller l'univers des idées de contrôle de source jusqu'à ce qui est devenu Git. Dites-moi, quels ont été les choix non évidents que vous avez faits à l'époque ?
Linus Torvalds : Le fait que vous disiez que c'est évident maintenant, je pense que ce n'était pas évident à l'époque. Je pense que l'une des raisons pour lesquelles les gens ont trouvé Git très difficile à utiliser est que la plupart des personnes qui ont commencé sans utiliser Git venaient d'un contexte de type CVS. Et l'état d'esprit de Git, je l'ai abordé d'un point de vue de personne de système de fichiers, où j'avais ce dédain et presque de la haine pour la plupart des projets de gestion de contrôle de source, donc je n'étais pas du tout intéressé par le maintien du statu quo.
Et le plus gros problème pour moi - eh bien, il y en avait deux énormes. L'un était la performance : à l'époque, j'appliquais encore beaucoup de correctifs, ce que Git a presque fait disparaître, car je ne fais plus que fusionner le code d'autres personnes.
Mais pour moi, l'un des objectifs était de pouvoir appliquer une série de correctifs en une demi-minute, même s'il s'agissait de 50 ou 100 correctifs.
Taylor Blau : Vous ne devriez pas avoir besoin d'un café pour...
Linus Torvalds : Exactement. Et c'était important pour moi parce que c'est en fait une question de qualité de vie. C'est l'une de ces choses où si les choses sont instantanées, si une erreur se produit, vous voyez immédiatement le résultat et vous continuez et vous le corrigez. Certains des autres projets que j'avais examinés prenaient environ une demi-minute par correctif, ce qui n'était pas acceptable pour moi. Et ce parce que le noyau est un projet très vaste et que beaucoup de ces SCM n'ont pas été conçus pour être évolutifs.
C'était donc l'un des problèmes. Mais l'un des problèmes était que je savais qu'il fallait que le système soit distribué, mais qu'il devait être vraiment, vraiment stable. Les gens pensent que l'utilisation des hachages SHA-1 a été une énorme erreur. Mais pour moi, les hachages SHA-1 n'ont jamais été une question de sécurité. Il s'agissait de trouver la corruption.Et c'était important pour moi parce que c'est en fait une question de qualité de vie.
En effet, nous avions déjà rencontré ce problème avec BitKeeper, qui utilisait des CRC et des MD5, mais qui ne les utilisait pas pour tout. L'une des premières idées que j'ai eues, c'est qu'absolument tout était protégé par un très bon hachage.
C'est ce qui a guidé l'ensemble du projet, avec deux ou trois idées de conception fondamentales. C'est pourquoi, à un bas niveau, il est en fait assez simple, mais la complexité réside dans les détails, les interfaces utilisateur et toutes les choses qu'il doit être capable de faire - parce que tout le monde veut qu'il fasse des choses folles. Mais le fait d'avoir une conception de bas niveau avec quelques concepts de base a facilité l'écriture, la réflexion et, dans une certaine mesure, l'explication des idées aux gens.
Je compare cela à Unix. Unix a comme philosophie de base que tout est un processus, tout est un fichier, on fait passer des choses entre les choses. En réalité, ce n'est pas si simple. Il y a les concepts simples qui sous-tendent la philosophie, mais tous les détails sont très compliqués.
Je pense que c'est ce qui m'a fait apprécier Unix en premier lieu. Et je pense que Git a un peu le même genre de caractéristiques, il y a une simplicité fondamentale dans la conception et puis il y a la complexité de l'implémentation.
Taylor Blau : Il y a un lien entre Unix et la façon dont Git a été conçu.
Linus Torvalds : Oui.
Taylor Blau : Vous avez parlé de SHA-1. L'une des choses auxquelles je pense au cours de la semaine ou des deux semaines où vous avez développé la première version de Git, c'est que vous avez pris beaucoup de décisions qui sont restées dans les mémoires.
Linus Torvalds : Oui, c'est vrai.
Taylor Blau : Y en a-t-il eu, y compris SHA-1 ou non, que vous avez regrettées ou que vous auriez voulu faire différemment ?
Linus Torvalds : Eh bien, je veux dire que je regrette SHA-1 dans le sens où je pense qu'il a causé beaucoup d'agitation inutile avec l'idée d'essayer de supporter SHA-256 aussi bien que SHA-1. Je comprends pourquoi c'est arrivé, mais je pense que c'était surtout inutile.
Je ne pense pas qu'il y ait eu un besoin énorme et réel, mais les gens étaient inquiets, alors c'était court. Je pense donc qu'il y a eu beaucoup d'efforts gaspillés. Il y a un certain nombre d'autres petits problèmes. Je pense que j'ai fait une erreur dans la façon dont les entrées du fichier d'index sont triées. Je pense qu'il y a ces détails stupides qui ont rendu les choses plus difficiles qu'elles ne devraient l'être.
Mais en même temps, beaucoup de ces choses pourraient être corrigées, mais elles sont suffisamment petites. Cela n'a pas vraiment d'importance. Toutes les complexités sont ailleurs en fin de compte.
Taylor Blau : Il semble donc que vous ayez peu de regrets. Je pense que c'est une bonne chose. Y a-t-il eu des moments où vous n'étiez pas sûr que ce que vous essayiez de réaliser allait fonctionner, s'assembler ou être utilisable ? Ou aviez-vous déjà une idée assez claire ?
Linus Torvalds : J'avais une idée claire des étapes initiales, mais je n'étais pas sûr de la façon dont cela fonctionnerait à long terme. Honnêtement, après la première semaine, j'avais quelque chose de bien pour appliquer les correctifs, mais pas vraiment pour le reste. J'avais les bases pour faire des fusions, et les structures de données étaient en place pour cela, mais cela a pris, je crois, une semaine de plus avant que je ne fasse ma première fusion.
Il y a un certain nombre de choses pour lesquelles j'avais une vue d'ensemble et un résultat en tête, mais je n'étais pas sûr d'y arriver. Oui, les premiers pas, je veux dire la première ou les deux premières semaines, vous pouvez aller voir le code - et les gens l'ont fait - et ce n'est pas un code compliqué.
Taylor Blau : Non.
Linus Torvalds : Je crois que la première version faisait 10 000 lignes ou quelque chose comme ça.
Taylor Blau : Vous pouvez plus ou moins le lire en une seule séance.
Linus Torvalds : Oui, et il est assez simple et ne fait pas beaucoup de vérifications d'erreurs et d'autres choses de ce genre. Il s'agit vraiment d'un « Faisons-le fonctionner parce que j'ai un autre projet que je considère comme plus important que celui auquel je dois me consacrer ». C'était vraiment le cas. Il m'arrivait de rencontrer des problèmes qui m'obligeaient à faire des changements.
« Il y a eu un certain nombre de choses pour lesquelles j'avais une vue d'ensemble et un résultat en tête, mais je n'étais pas sûr d'y arriver. »
Linus Torvalds : La première version - je pense que nous avons fini par faire un transfert de magasin d'objets incompatible à un moment donné. Au moins, fsck se plaint de certains des anciens objets que nous avions parce que j'ai changé le format des données.
Taylor Blau : Je ne savais pas d'où cela venait.
Linus Torvalds : Oui, non. La première version ne faisait pas tout ce qu'elle devait faire.
Et j'ai oublié si j'avais fait une conversion ou non. Il se peut que je n'aie jamais eu besoin de convertir. Et nous avons juste quelques avertissements pour quelques objets dans le noyau où fsck dira, « Hé, c'est un ancien format qui n'est plus supporté ». Ce genre de choses. Mais d'un autre côté, dans l'ensemble, cela a vraiment fonctionné, je veux dire, étonnamment bien.
Le gros problème a toujours été l'acceptation par les gens.
Taylor Blau : C'est vrai.
Linus Torvalds : Et cela a pris beaucoup de temps.
« Mais d'un autre côté, dans l'ensemble, ça a vraiment marché, je veux dire, étonnamment bien. »
Taylor Blau : Nous avons un peu parlé du fait que la fusion a été mise en place mais qu'elle n'a pas été fonctionnelle avant la deuxième ou la troisième semaine. Quelles sont les autres fonctionnalités que vous avez laissées de côté dans la version initiale et dont vous vous êtes rendu compte plus tard qu'elles étaient en fait essentielles au projet ?
Linus Torvalds : Eh bien, ce n'est pas tant « réalisé plus tard », c'était des choses dont je ne me souciais pas, mais je savais que si cela devait aller quelque part, quelqu'un d'autre le ferait. La première semaine où je l'ai utilisé pour le noyau, j'utilisais littéralement les commandes brutes, ce qu'on appelle aujourd'hui les « commandes de plomberie », à la main.
Taylor Blau : C'est évident.
Linus Torvalds : Parce qu'il n'y avait pas de porcelaine. Il n'y avait rien au-dessus pour le rendre utilisable. Donc, pour faire un commit, vous faisiez ces choses très obscures.
Taylor Blau : Définir l'index, faire un commit-tree.
Linus Torvalds : Oui, commit-tree, écrit, et cela renvoie juste un SHA que vous écrivez à la main dans le fichier head et c'est tout.
Taylor Blau : Est-ce que hash-object existait dans la première version ?
Linus Torvalds : Je pense que c'était l'un des premiers binaires que j'avais où je pouvais simplement vérifier que je pouvais tout hacher à la main et il renvoyait le hachage en standard, puis vous pouviez faire ce que vous vouliez avec. Mais c'était comme si le début de la porcelaine était moi en train de faire des scripts shell autour de ces choses très difficiles à utiliser.
Et honnêtement, ce n'était pas facile à utiliser même avec mes scripts shell.
Mais pour être juste, le premier public cible de ce projet était composé de personnes qui utilisaient BitKeeper. Ils connaissaient au moins une bonne partie des concepts que j'avais en tête. Les gens l'ont adopté.
Il n'a pas fallu longtemps pour que d'autres développeurs du noyau commencent à l'utiliser. J'ai été surpris par la rapidité avec laquelle des personnes chargées du contrôle des sources ont commencé à intervenir. Et j'ai commencé à recevoir des correctifs de l'extérieur quelques jours après avoir fait la première version publique de Git.
Taylor Blau : Je voudrais aller un peu plus loin. Vous avez pris la décision de confier la maintenance à Junio assez tôt dans le projet. Pourriez-vous me parler un peu de ce que c'est que de le voir gérer le projet et de voir la communauté interagir avec lui avec un peu de distance après toutes ces années ?
Linus Torvalds : Pour être honnête, j'ai géré Git pendant trois ou quatre mois. Je crois que je l'ai cédé en août [2005] ou quelque chose comme ça.
Et quand je l'ai abandonné, je l'ai vraiment abandonné. Je me suis dit : « Je suis toujours là. » Je lisais encore la liste de diffusion Git, ce que je ne fais plus. Junio voulait s'assurer que s'il me demandait quoi que ce soit, je serais d'accord.
Mais en même temps, je me disais que ce n'était pas ce que je voulais faire. Je veux dire, c'est... Je me sens encore idiot. Ma fille aînée est partie à l'université et, deux mois plus tard, elle m'a envoyé un message pour me dire que j'étais plus connu au laboratoire d'informatique pour Git que pour Linux, parce qu'ils utilisent Git pour tout. J'ai répondu que Git n'avait jamais été une chose importante pour moi. Git, c'était « je dois faire ça pour faire le noyau ». Et c'est un peu ridicule que, oui, j'ai utilisé quatre mois de ma vie pour le maintenir, mais maintenant, 20 ans plus tard...
Oui, c'est à Junio qu'il faut s'adresser, pas à moi, parce qu'il a fait un excellent travail et que je suis très heureux que les choses se soient si bien passées. Mais pour être honnête, je dois reconnaître que j'ai travaillé avec des gens sur Internet pendant suffisamment longtemps pour savoir - pendant les quatre mois où j'ai assuré la maintenance de Git - qui avait le bon goût d'être un bon mainteneur.
Taylor Blau : C'est de cela qu'il s'agit, du goût pour vous.Ma fille aînée est partie à l'université et, deux mois plus tard, elle m'envoie un message pour me dire que je suis plus connu au laboratoire d'informatique pour Git que pour Linux, parce qu'ils utilisent Git pour tout.
Linus Torvalds : Pour moi, c'est difficile à décrire. On peut le voir dans les correctifs, dans la façon dont ils réagissent au code des autres, dans leur façon de penser. Junio n'a pas été le premier à participer au projet, mais il a été l'un des premiers à être présent dès la première semaine, après que j'ai rendu le projet public.
Il a donc été l'une des premières personnes - mais ce n'était pas comme si vous étiez le premier, et que vous étiez le seul. C'était plutôt du genre : « Bon, j'ai vu cette personne travailler pendant trois mois et je ne veux pas maintenir ce projet. Je vais lui demander s'il veut être le mainteneur. Je pense qu'il était un peu nerveux au début, mais cela a vraiment bien fonctionné.
Taylor Blau : Oui, il a certainement dirigé le projet de façon admirable dans les...
Linus Torvalds : Oui, je veux dire, le goût est très important pour moi, mais d'un point de vue pratique, le fait de rester dans un projet pendant 20 ans, c'est encore plus important, n'est-ce pas ? Et il l'a fait.
Taylor Blau : Je pense qu'il connaît étonnamment bien presque tous les aspects de l'arbre.
Nous avons beaucoup parlé des débuts de Git. Je voudrais parler un peu de la période intermédiaire de Git, ou peut-être même de la période dans laquelle nous nous trouvons actuellement.
L'une des choses que je trouve intéressantes à propos de cet outil, étant donné son omniprésence, c'est qu'il a clairement été efficace pour aider au développement du noyau, mais il a aussi été très efficace pour les étudiants universitaires qui écrivent de petits projets de classe sur leurs ordinateurs portables. Qu'est-ce qui, selon vous, a rendu Git efficace aux deux extrêmes du spectre du génie logiciel ?
Linus Torvalds : La nature distribuée de Git facilite beaucoup de choses et c'est ce qui le différencie de la plupart des SCM. Il y a déjà eu des SCM distribués, mais, à ma connaissance, il n'y a jamais eu quelque chose où c'était l'objectif de conception numéro un - avec les autres objectifs de conception numéro un - où l'on peut travailler avec Git uniquement localement et où, plus tard, si l'on veut le rendre disponible ailleurs, c'est très facile.
C'est très différent de CVS, par exemple, où il faut mettre en place ce type de dépôt et où, si l'on veut le déplacer ailleurs, c'est très pénible et on ne peut pas le partager avec quelqu'un d'autre sans en perdre la trace.
Il y aura toujours un dépôt spécial quand on utilise un SCM traditionnel et le fait que Git n'ait pas fait ça, et qu'il ne l'ait pas fait par conception, c'est ce qui a rendu des services comme GitHub triviaux. Je veux dire que je banalise GitHub parce que je me suis rendu compte qu'il y avait beaucoup de travail pour créer toute l'infrastructure autour de Git, mais en même temps le site d'hébergement Git de base n'est pratiquement rien parce que tout le design de Git est conçu pour faciliter la copie, et que chaque dépôt est le même et égal.
Et je pense que c'est ce qui l'a rendu si facile à utiliser en tant que développeur individuel. Lorsque vous créez un nouveau dépôt Git, ce n'est pas grand-chose. C'est comme dans Git et c'est fini. Vous n'avez pas besoin de mettre en place une infrastructure ni de faire les choses que vous deviez traditionnellement faire avec un SCM. Et si ce projet prend de l'ampleur et que vous décidez de le confier à d'autres personnes, cela fonctionne également. Là encore, vous n'avez rien à faire. Il suffit de l'envoyer sur GitHub et le tour est joué.
C'est quelque chose que je voulais vraiment. Je n'avais pas réalisé combien d'autres personnes le voulaient aussi. Je pensais que les gens étaient satisfaits de CVS et SVN. Je ne le pensais pas vraiment, mais je pensais qu'ils étaient suffisants pour la plupart des gens, disons-le comme ça.
Taylor Blau : J'ai vécu toute ma vie avec le contrôle de version dans le cadre du développement de logiciels, et l'une des choses qui m'intéressent est de savoir comment vous voyez le rôle de Git dans la façon dont le développement de logiciels se fait aujourd'hui.
Linus Torvalds : C'est une question trop vaste pour moi. Je n'en sais rien. Ce n'est pas pour cela que j'ai écrit Git. Je l'ai écrit pour mes propres problèmes.
Je pense que GitHub et les autres services d'hébergement ont montré à quel point il est facile de créer tous ces petits projets aléatoires d'une manière qui n'existait pas auparavant. Cela a également entraîné la disparition de nombreux projets. On trouve des projets ponctuels où quelqu'un a fait quelque chose et l'a laissé derrière lui, mais il est toujours là.
Mais cela change-t-il vraiment la façon dont le développement de logiciels est effectué dans l'ensemble ? Je n'en sais rien. Je veux dire que cela change les détails. Cela facilite la collaboration dans une certaine mesure. Il est plus facile de réaliser ces projets improvisés. Et s'ils ne fonctionnent pas, ils ne fonctionnent pas. Et s'ils fonctionnent, vous pouvez maintenant travailler avec d'autres personnes. Mais je ne suis pas sûr que cela ait changé quoi que ce soit de fondamental dans le développement de logiciels.
« Cela facilite la collaboration dans une certaine mesure. »
Taylor Blau : Pour aller un peu plus loin, le développement de logiciels modernes n'a jamais évolué aussi vite qu'aujourd'hui...
Linus Torvalds : Allez-vous prononcer le mot « IA » ?
Taylor Blau : Je ne vais pas prononcer le mot « IA », à moins que vous ne le vouliez.
Linus Torvalds : Non, non, non.
Taylor Blau : ... quels sont les aspects de l'outil qui, selon vous, ont évolué ou doivent encore évoluer pour continuer à prendre en charge les flux de travail nouveaux et exigeants pour lesquels les gens l'utilisent ?
Linus Torvalds : J'aimerais voir plus de suivi de bogues. Tout le monde le fait. Qu'on l'appelle suivi de bogues, problèmes ou autre, j'aimerais qu'il soit plus unifié. Parce que pour l'instant, c'est très fragmenté et chaque site d'hébergement en fait sa propre version.
Et je comprends pourquoi ils le font. A, il n'y a pas de bonne base standard. Et B, c'est aussi un moyen d'apporter de la valeur ajoutée et de garder les gens dans cet écosystème, même si Git lui-même signifie qu'il est très facile de déplacer le code.
Mais j'aimerais qu'il y ait un système plus unifié où le suivi des bogues et les problèmes en général seraient plus partagés entre les sites d'hébergement.
Taylor Blau : Vous avez mentionné plus tôt que cela faisait au moins un moment que vous n'aviez pas suivi régulièrement la liste de diffusion.
Linus Torvalds : Oui, c'est vrai.
Taylor Blau : En fait, cela fait même un petit moment que vous ne vous êtes pas engagé dans le projet. Je pense que d'après mes calculs, la dernière fois c'était en août 2022...
Linus Torvalds : Oui, j'ai quelques patchs expérimentaux dans mon arbre que je garde. Ces jours-ci, je consulte les sources Git et j'ai, je crois, quatre ou cinq correctifs que j'utilise moi-même. Je crois que j'en ai envoyé quelques-uns à la liste de diffusion Git, mais ils ne sont pas très importants. Ce sont des détails qui sont très spécifiques à mon flux de travail.
Mais honnêtement, je veux dire, c'est aussi vrai pour le noyau Linux. Je travaille sur Linux depuis 35 ans, et il a fait tout ce dont j'avais besoin la première année, n'est-ce pas ? Et ce qui me fait continuer à travailler sur le noyau, c'est que, A, le matériel évolue sans cesse, et le noyau doit évoluer avec lui, bien sûr. Mais B, ce sont tous les besoins des autres. Jamais dans ma vie je n'aurais besoin de toutes les fonctionnalités du noyau. Mais je m'intéresse aux noyaux, et je continue à le faire 35 ans plus tard.
En ce qui concerne Git, c'est comme si Git avait fait ce dont j'avais besoin dès la première année. En fait, surtout au cours des premiers mois. Et quand il a fait ce dont j'avais besoin, j'ai perdu tout intérêt. Parce que lorsqu'il s'agit de noyaux, je suis vraiment intéressé par leur fonctionnement, et c'est ce que je fais. Mais lorsqu'il s'agit de SCM, c'est comme si je n'étais pas du tout intéressé.
Taylor Blau : Y a-t-il des fonctionnalités du projet que vous avez suivies au cours des dernières années et que vous avez trouvées intéressantes ?Quand il s'agit de Git, c'est comme si Git avait fait ce dont j'avais besoin au cours de la première année. En fait, la plupart du temps au cours des premiers mois.
Linus Torvalds : J'ai apprécié le fait que les stratégies de fusion soient devenues légèrement plus intelligentes. J'ai aimé le fait que certains scripts aient finalement été réécrits en C pour les rendre plus rapides, car même si je n'applique plus 100 séries de correctifs, je finis par faire des choses comme le rebasage des arbres de test et d'autres choses de ce genre et je bénéficie de certaines améliorations de performance.
Mais, je veux dire, ce sont des détails d'implémentation assez petits en fin de compte. Je pense que le plus grand changement que je suivais encore il y a quelques années était cette histoire de hachages multiples, qui me semble vraiment très pénible.
Taylor Blau : Y a-t-il des outils dans l'écosystème que vous avez utilisés en parallèle ? Je veux dire que je suis moi-même un grand utilisateur de tig. Je ne sais pas si vous l'avez déjà utilisé.
Linus Torvalds : Je n'ai jamais - non, même au début quand nous avions, comme quand Git était vraiment difficile à utiliser et qu'il y avait des interfaces utilisateur supplémentaires, le seul wrapper autour de Git que j'ai jamais utilisé était gitk. Et il a été intégré à Git assez rapidement, n'est-ce pas ? Mais j'utilise toujours le langage de commande dans son intégralité. Je n'utilise pas l'intégration de l'éditeur. Je ne fais rien de tout cela parce que mon éditeur est trop stupide pour s'intégrer à quoi que ce soit, et encore moins à Git.
Il m'arrive de faire des statistiques sur l'utilisation de mon historique Git, juste parce que je me demande quelles commandes j'utilise. Et il s'avère que j'utilise cinq commandes Git. Et git merge, git blame et git log sont trois d'entre elles, à peu près. Je suis donc un utilisateur très occasionnel de Git.
Taylor Blau : J'aimerais savoir ce que sont les deux autres.
Linus Torvalds : Je veux dire évidemment git commit et git pull. J'ai fait ce truc du top 5 à un moment donné et ça a peut-être changé, mais il n'y a pas beaucoup de - j'ai quelques scripts qui utilisent git rev-list et qui vont très bas et font des statistiques pour le projet...
Taylor Blau : En ce qui concerne votre interaction avec le projet, quelles sont, selon vous, les fonctionnalités du projet, que ce soit au début ou depuis, qui n'ont peut-être pas été appréciées à leur juste valeur ?
Linus Torvalds : Je veux dire que Git a été beaucoup plus apprécié qu'il ne le mérite. Mais c'est l'inverse de la question que je me poserais. Ce qui m'a le plus marqué, c'est que les gens ont commencé à apprécier ce que Git pouvait faire au lieu de se plaindre de sa différence.
Et ça, je veux dire, c'était plusieurs années après le premier Git. Je pense que ce sont ces étranges développeurs web qui ont commencé à utiliser Git à grande échelle. C'est comme Ruby on Rails, je crois. Je n'avais aucune idée, je ne sais toujours pas ce qu'est Ruby. Mais les gens de Ruby on Rails ont commencé à utiliser Git en 2008, quelque chose comme ça.
C'était étrange parce que cela a amené un tout nouveau type d'utilisateur de Git, du moins un que je n'avais pas vu auparavant. Il devait exister en arrière-plan, mais il était évident que tous ces jeunes gens qui n'avaient jamais utilisé de SCM auparavant utilisaient Git pour la première fois, et c'était ce que le projet qu'ils utilisaient utilisait, de sorte que c'était en quelque sorte la solution par défaut.
Je pense que cela a changé la dynamique. Quand il n'y a plus ces anciens qui ont utilisé un SCM très différent toute leur vie, et que soudain vous avez des jeunes qui n'ont jamais rien vu d'autre et qui l'apprécient, au lieu de dire « Git est si difficile “, j'ai commencé à voir ces gens qui se plaignaient de ” Comment faire ceci alors que ce vieux projet est dans CVS ? C'était amusant.
Mais oui, non. Le fait que les gens apprécient Git, je veux dire, bien plus que je ne l'aurais jamais pensé. Surtout si l'on considère les premières années où j'ai reçu beaucoup de haine à son sujet.
Taylor Blau : Vraiment ?
Linus Torvalds : Oh, les plaintes n'ont pas cessé d'affluer.
Taylor Blau : Parlez-moi de cela.
Linus Torvalds : Oh, je veux dire, c'est plus comme si je ne pouvais pas donner de détails. Il faut chercher sur Google. Mais le nombre de personnes qui m'ont envoyé « Pourquoi ça fait ça ? » Et les guerres de flammes à propos de mon choix de noms. Par exemple, je n'avais pas git status, qui est en fait l'une des commandes que j'utilise assez régulièrement maintenant.
Taylor Blau : C'est dans le top 5 ?
Linus Torvalds : Ce n'est probablement pas dans le top 5, mais c'est quand même quelque chose d'assez courant. Je ne pense pas l'avoir jamais utilisée avec CVS parce qu'elle était si lente.
Et les gens avaient toutes ces attentes. Je me souviens donc des premières années, des plaintes concernant les noms des sous-commandes qui étaient différents sans raison valable. Et la raison principale était que je n'aimais pas beaucoup CVS, alors je faisais parfois les choses différemment.
J'ai trouvé intéressant le changement qui s'est opéré entre 2007 et 2010, lorsque les gens ont commencé à se plaindre de la difficulté d'utilisation de Git pour ensuite en apprécier toute la puissance.
Taylor Blau : J'aimerais prendre quelques instants pour réfléchir à l'avenir du projet. Selon vous, quels sont les plus grands défis auxquels Git est ou sera confronté ?
Linus Torvalds : Je n'en sais rien. Je veux dire qu'il a eu tellement plus de succès que je n'en ai jamais eu... Je veux dire, les statistiques sont folles. Il est passé d'une utilisation pour le noyau et quelques autres projets à une utilisation assez populaire, pour atteindre aujourd'hui 98% des SCMs utilisés. C'est un chiffre que j'ai vu dans un rapport de l'année dernière.
Je ne sais pas à quel point c'est vrai, mais c'est énorme. Et dans ce sens, je ne m'inquiéterais pas des défis parce que je pense que les SCMs ont un effet de réseau très fort. Et c'est probablement la raison pour laquelle, une fois qu'il a décollé, il a décollé de façon importante. Lorsque tous les autres projets utilisent Git, par défaut, tous les nouveaux projets utilisent également Git. Parce que cela ne vaut pas la peine d'avoir deux SCM différents pour deux projets différents.
Je ne vois donc pas cela comme un défi pour Git, mais plutôt comme un défi pour tous ceux qui pensent avoir quelque chose de mieux. Et honnêtement, parce que Git fait tout ce dont j'ai besoin, les défis viendraient probablement des nouveaux utilisateurs.
C'est ce que nous avons constaté. Nous l'avons vu avec des personnes qui ont utilisé Git d'une manière que je considère explicitement comme une mauvaise approche. Comme Microsoft, la monorepo pour tout, qui a montré des problèmes d'évolutivité. Je ne dis pas que Microsoft a eu tort de faire cela. Je dis que c'est littéralement ce pour quoi Git n'a pas été conçu.
Je suppose que la plupart de ces problèmes ont été résolus parce que je ne vois pas de plaintes, mais en même temps je ne suis plus la liste de diffusion de Git autant qu'avant.
Je ne sais même pas si le problème des gros fichiers est considéré comme résolu. Si vous voulez mettre une image de DVD dans Git, c'est du genre, pourquoi voudriez-vous faire ça ?
Mais, je veux dire, c'est le défi. Lorsque Git est omniprésent, on trouve tous ces gens qui font des choses étranges que l'on n'imaginerait jamais - que je n'imaginais pas et que je considère comme des erreurs flagrantes.
Mais bon, c'est une opinion personnelle. Il est clair que d'autres personnes ont des opinions personnelles très différentes. C'est donc toujours un défi. Je veux dire que c'est quelque chose que je vois aussi dans le noyau, où je me demande pourquoi diable vous faites ça ? Cela ne devrait pas fonctionner, mais c'est pourtant ce que vous faites.
Taylor Blau : Nous avons parlé du fait que Git est manifestement un élément dominant dans le développement de logiciels. En même temps, il y a de nouvelles entreprises de contrôle de version qui semblent apparaître. Pijul me vient à l'esprit, Jujutsu, Piper, etc. Je suis curieux de savoir si vous avez déjà essayé l'un d'entre eux.Lorsque Git est omniprésent, on trouve des gens qui font des choses étranges que l'on n'imaginerait jamais, que je n'imaginais pas et que je considère comme des erreurs flagrantes.
Linus Torvalds : Non, je n'en ai jamais essayé. Je veux dire, littéralement, puisque je suis parti de là, de l'absence totale d'intérêt pour le contrôle de source, pourquoi chercherais-je des alternatives maintenant que j'ai quelque chose qui fonctionne pour moi ?
Je suis arrivé à Git en n'aimant pas le contrôle de source, et maintenant je ne le déteste plus. Et je pense que les bases de données sont particuliers - c'est la chose la plus ennuyeuse de ma vie. Mais les SCM ne sont toujours pas quelque chose qui m'intéresse vraiment.
« Je suis arrivé à Git en n'aimant pas le contrôle de source, et maintenant je ne le déteste plus. »
Taylor Blau : Vous m'avez permis de mettre un terme à la dernière question que j'avais à vous poser. Donc, Linux est arrivé il y a 34 ans, Git il y a 20 ans...
Linus Torvalds : Oh, cette question.
Taylor Blau : Nous sommes donc en retard d'environ cinq ans pour le prochain grand projet.
Linus Torvalds : Non, non, je vois les choses dans l'autre sens. Tous les projets que j'ai dû réaliser, je l'ai fait parce que je n'ai rien trouvé de mieux que quelqu'un d'autre.
Mais je préfère de loin que d'autres personnes résolvent mes problèmes à ma place. Ainsi, le fait que je doive proposer un projet est en fait un échec du monde - et le monde n'a tout simplement pas échoué au cours des 20 dernières années en ce qui me concerne.
J'ai commencé à faire Linux parce que j'avais besoin d'un système d'exploitation et qu'il n'y avait rien qui correspondait à mes besoins. J'ai commencé à faire Git pour la même raison. Et il n'y a pas eu de... J'ai commencé Subsurface, qui est mon logiciel de plongée, enfin, qui n'est plus mon logiciel de plongée, mais qui était tellement spécialisé qu'il n'a jamais décollé de manière importante. Cela a permis de résoudre un problème particulier, mais mon utilisation de l'ordinateur est tellement limitée que je pense avoir résolu tous les problèmes.
C'est probablement dû en partie au fait que je fais cela depuis si longtemps que je ne peux faire les choses que d'une certaine manière. J'utilise toujours le même éditeur que lorsque j'étais à l'université parce que mes doigts ont appris une chose et qu'il n'y a pas de retour en arrière possible. Je sais que l'éditeur est mauvais et je le maintiens parce que c'est un projet mort que personne d'autre n'utilise.
J'ai donc un arbre des sources et je compile ma propre version à chaque fois que j'installe une nouvelle machine et je suggérerais que personne n'utilise jamais cet éditeur, mais je ne peux pas. J'ai essayé plusieurs fois de trouver un éditeur plus moderne et qui fait des choses fantaisistes comme coloriser mon code source et faire des choses comme ça. Et à chaque fois que j'essaie, je me dis : « Ouais, ces mains sont trop vieilles pour ça. » Alors j'espère vraiment qu'il n'y aura pas de projet qui me fera dire : « Il faut que je fasse ça. »Mais je préfère de loin que d'autres personnes résolvent mes problèmes à ma place. Ainsi, le fait que je doive trouver un projet est en fait un échec du monde - et le monde n'a tout simplement pas échoué au cours des 20 dernières années pour moi.
Taylor Blau : Eh bien, sur ce point.
Linus Torvalds : Sur ce point.
Taylor Blau : Merci pour 20 ans de Git.
Linus Torvalds : Je l'ai fait pour des raisons très égoïstes. Et vraiment - je veux dire, c'est le moment de répéter que oui, sur les 20 ans, j'ai passé quatre mois dessus. Tout le mérite en revient donc à Junio et à toutes les autres personnes impliquées dans Git, qui ont déjà fait bien plus que moi.
Taylor Blau : Quoi qu'il en soit, je vous remercie.
Si vous voulez en savoir plus sur l'outil de contrôle de sources distribué Git, voici le tutoriel Pro Git. Pro Git a été écrit pour aider les développeurs professionnels à apprendre l'outil de contrôle distribué Git. Vous apprendrez pourquoi Git est différent et puissant, comment l'utiliser en commençant par des exemples simples et avancés, puis comment faire une transition vers Git à partir d'un système déjà installé.
Et vous ?
Pensez-vous que les propos de Linus Torvalds sont crédibles ou pertinents ?
Voir aussi :
Répondre avec citation
Partager