Git a 20 ans : questions et réponses avec Linus TorvaldsPour 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. »
...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.
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.
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é.
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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.