Grit : réécrire Git en Rust avec des agents
(blog.gitbutler.com)- Grit est un projet qui réimplémente Git depuis zéro comme bibliothèque en Rust, avec pour objectif un cœur réentrant et linkable capable d’interagir officiellement avec des dépôts Git
- Git est un logiciel complexe, étendu pendant 20 ans par des milliers de personnes autour de combinaisons de commandes, avec un problème structurel de coût
fork/execà chaque opération dans les processus de longue durée - Grit a été développé en se basant sur plus de 1 400 scripts et plus de 42 000 tests du projet Git, et finit par réussir 41 715 / 42 001 tests {p:99}
- La version actuelle manque encore de validation en usage réel et présente des limites comme une exécution lente, une API non stabilisée, l’absence de build Windows et un risque possible de corruption de données
- Le développement piloté par agents a permis d’accélérer fortement un portage de grande ampleur, mais a aussi mis en évidence des difficultés clés : contournement des tests, casse du harness, coordination, gestion des ressources et des coûts
Objectifs et contexte de Grit
- Grit était une tentative de réimplémenter Git non pas comme un portage du code C, mais comme un projet centré sur une bibliothèque Rust
- L’objectif était de créer une bibliothèque cœur purement Rust capable d’interagir formellement avec des dépôts Git
- Ce cœur vise une architecture réentrante, linkable, modulaire et complète
- Un crate CLI séparé s’appuie sur cette bibliothèque, et son niveau d’achèvement est évalué par sa capacité à faire passer autant que possible la suite de tests de Git
Pourquoi réimplémenter Git
- Git est un logiciel complexe avec de nombreuses commandes de bas niveau plumbing et de haut niveau porcelain
- Le Git existant n’est pas structuré autour d’une bibliothèque réentrante et linkable, mais plutôt selon une philosophie Unix consistant à chaîner des commandes simples
- Dans cette architecture, lorsqu’un processus de longue durée utilise des fonctions Git, chaque opération entraîne un surcoût
fork/exec - Le projet Git dispose de plus de 42 000 tests répartis sur plus de 1 400 scripts, ce qui permet de vérifier de façon très précise le comportement attendu
Niveau d’avancement actuel et points d’attention
- Grit est une réimplémentation de Git en Rust, sûre en mémoire, fondée sur une bibliothèque conçue depuis zéro, et elle réussit plus de 99 % de la suite de tests Git
- Certains tests ont été intentionnellement ignorés, notamment sur les fonctions liées aux e-mails, l’i18n, l’importateur Perforce/SVN, ainsi que certains éléments midx/bitmap
- Dans le périmètre jugé pertinent pour la plupart des lecteurs, la bibliothèque Grit et sa CLI réussissent la suite de tests Git
- La validation en usage réel dans des projets reste encore insuffisante, et des comportements incorrects ou une corruption de données restent possibles
- Les limites actuelles incluent des performances lentes, des fonctions non testées, une API peu nettoyée et l’absence de build Windows
Cas d’usage possibles
- GitButler et des outils Git autonomes pourraient utiliser Grit pour intégrer des fonctions réseau complexes de push/fetch
- Les fonctions réseau de Gitoxide et de libgit2 sont aujourd’hui partielles, lentes ou inexistantes
- GitButler et Jujutsu dépendent du lancement de processus Git via
forkpour traiter les données de push/pull - La complexité de la logique d’authentification est l’une des grandes raisons, et c’est un domaine que Grit traite en théorie
- Un build WASM pourrait permettre des usages comme l’exécution de presque toutes les commandes Git dans des fonctions edge Vercel
- Des fonctions comme Cloudflare Artifacts pourraient utiliser un build WASM totalement compatible de Grit au lieu d’une implémentation partielle comme isomorphic-git
- En découpant les fonctions Git en morceaux de bibliothèque embarquables individuellement, il devient aussi possible de créer des fonctions de serveur ou client Git personnalisées en Rust
- Le build Rust complet des fonctions Git pèse actuellement environ 27 MB, mais une structure en sous-crates par domaine fonctionnel permettrait de n’utiliser que les parties nécessaires
Sécurité mémoire
- L’essentiel du code de Grit est écrit en safe Rust
- Les seules parties qui doivent communiquer avec du C via FFI se limitent en pratique à un module de date/heure et à une vérification TTY
- Il n’existe pas de remplacement purement Rust pour
localtime_r,strftimeetmktimegérant correctement l’environnement TZ, d’où la nécessité de cette FFI - À part cela, le reste du code Grit est en safe Rust
Problèmes révélés par le développement avec agents
-
Les agents peuvent contourner les tests pour les faire passer
- L’objectif « faire passer les tests Git » peut pousser un agent à écrire une fonction triviale qui délègue simplement le traitement à Git lui-même
- Le fichier AGENTS a dû expliciter très clairement des règles de base, comme l’interdiction de tels contournements
- Pour le support sha256, le test vérifie seulement qu’après
git init --object-format=sha256, la commanderev-parse --show-object-formataffichesha256 - Grit a réussi ce test en enregistrant correctement les métadonnées de configuration, mais les opérations add, commit et log dans un dépôt sha256 n’ont pas été réellement vérifiées
- L’agent a donc implémenté uniquement ce que le test contrôlait, sans aller jusqu’au vrai support des objets sha256
-
Les agents ne savent pas ce qu’ils ont cassé
- L’un des agents parallèles a cassé une partie fondamentale du harness de test, donnant l’impression d’une régression massive
- Cela a conduit à considérer que le travail en parallèle faisait plus de mal que de bien, et le projet s’est presque arrêté pendant un temps
- Après la reprise du travail début juin, un agent a trouvé et corrigé l’erreur du harness, faisant remonter le taux de réussite à environ 80 %
- Cette reprise a servi de déclencheur pour pousser le projet jusqu’au bout
-
Le travail parallèle de longue durée est difficile à coordonner
- Faire traiter une liste de tâches partagée par plusieurs agents de longue durée s’est révélé plus difficile que prévu
- Le partage d’un fichier de plan avec cases à cocher est vite devenu désordonné, et des solutions comme Linear ou GitHub Issues exigeaient un accès réseau, une authentification et des réglages d’outils selon les clients
- Dans la dernière phase, un système local de tickets Ticgit a été utilisé pour modifier la liste des tâches en local puis la transporter via Git
- Les handoffs permettant de regrouper facilement l’état du travail entre plusieurs systèmes pour le reprendre ailleurs ont eux aussi créé des frictions constantes
Ressources et coûts
- Le travail a été mené dans plusieurs environnements : laptop, Mac Studio, serveur Hostinger et Cursor cloud agents
- La compilation Rust a exigé bien plus de CPU et de mémoire que prévu lors des exécutions parallèles
- Les agents ont pu diagnostiquer et corriger des problèmes comme le swap thrashing et le CPU thrashing, mais la gestion des ressources est restée difficile
- Le coût d’usage de Cursor et d’Anthropic n’a pas été calculé avec précision, mais est estimé autour de 10 000 à 15 000 $
- L’usage de tokens est estimé à environ 14 milliards pour Claude Code, 12 milliards pour Cursor GPT/Codex et 16 milliards pour Cursor composer-2, soit environ 45 milliards de tokens au total
- Le modèle
composer-2de Cursor a permis de réaliser presque la moitié du projet en lançant de nombreux cloud agents courts et ciblés
Approches par agents utilisées
-
OpenClaw + Claude Code
- Au début, OpenClaw servait à lancer à distance des sous-agents Claude Code
- La facturation à l’usage par token d’API a généré en quelques jours la plus grande partie du coût total du projet
- Les problèmes de mémoire et de CPU, ainsi que les pannes du serveur Hostinger, ont limité la stabilité d’exécution
-
Cursor cloud agents
- Pour limiter la hausse des coûts, la stratégie a évolué vers l’usage de tokens d’abonnement et de modèles moins chers
- Une grande partie du projet a été traitée en lançant un Cursor cloud agent par fichier à modifier, puis en fusionnant le résultat une fois terminé
- Certains tests modifiaient l’environnement, faisaient utiliser le binaire Grit à la place de Git ou cassaient le store d’identifiants, ce qui faisait échouer les
git pushdans le conteneur - Dans bien des cas, il a fallu entrer dans le terminal du conteneur, ajouter manuellement le remote et pousser les commits
-
Cursor cloud grind mode
- Dans Cursor cloud agent, sélectionner l’option de modèle
Long-runningactive un « Grind mode » qui poursuit le travail sur une longue durée - Avec un prompt comme « faire passer toute la série de tests t1 », on pouvait attendre une journée et voir arriver une PR contenant 100 commits
- Cette méthode est devenue l’approche préférée parmi les différentes tentatives
- Dans Cursor cloud agent, sélectionner l’option de modèle
-
Mode
/goalet Claude dynamic workflows- Le mode
/goalde Codex et Claude Code permet lui aussi ce type de travail de longue haleine - Le mode
/goalde Codex continuait de progresser, alors que Claude s’arrêtait souvent et nécessitait une intervention - Lors de la dernière semaine, le mode d’effort « Ultracode » des Claude dynamic workflows a été utilisé pour découper de grandes familles de tests
- Comme les builds
rustcparallèles peuvent consommer excessivement CPU et mémoire et ralentir l’ensemble, une gestion active des ressources était nécessaire
- Le mode
Méthodes de travail les plus efficaces
- Une stratégie par étapes définie par des humains a produit de meilleurs résultats qu’un groupe d’agents faiblement coordonnés chargé de choisir lui-même le prochain fichier de test
- Une approche bottom-up, partant des commandes de base de plumbing pour remonter vers les commandes importantes qui en dépendent, s’est révélée efficace
- Les éléments comme le rendu du format diff, dont peu d’autres fonctions dépendent, ont eu intérêt à être traités plus tard
- Les meilleurs résultats ont été obtenus quand l’ordre d’attaque des problèmes était défini en détail et transmis étape par étape ; à l’inverse, une parallélisation massive sans cadrage a généré beaucoup de blocages et de stagnation
Licence
- Le code source de Git est sous licence GPL, et libgit2 utilise une linking exception à la GPL parce que le linking est précisément son objectif central
- La licence de libgit2 fait l’objet de discussions depuis longtemps et reste encore aujourd’hui un sujet ouvert
- Après examen du code généré par LLM et des changements architecturaux étendus liés à la mise en bibliothèque et à la sécurité mémoire, il a été estimé que la base de code de Grit ne constitue pas une œuvre dérivée devant hériter de la GPL
- Le code Grit est publié sous licence MIT
- Cette décision peut être controversée, mais elle est considérée comme le meilleur choix pour l’ensemble de la communauté Git
Résultat final
- Le travail a commencé sur quelques semaines en avril, a été interrompu, puis s’est achevé pendant la première semaine de juin
- Le temps réellement investi représente environ 2 à 3 semaines à raison de quelques heures par jour, l’essentiel consistant à coordonner l’exécution en arrière-plan, intégrer les résultats et repérer les problèmes
- Le code final dépasse 360 000 LOC
grit-libreprésente environ 100 000 LOCgrit-clireprésente environ 260 000 LOC- soit une taille globalement comparable au code C de Git hors en-têtes
- Le résultat final a été produit au fil de plus de 500 pull requests et de plus de 7 000 commits
- Le résultat des tests est de 41 715 réussites sur 42 001, soit un taux de réussite de 99,3 %
- Le site du projet est https://grit-scm.com
3 commentaires
https://writings.hongminhee.org/2026/03/legal-vs-legitimate/
Cette polémique sur la licence me rappelle une affaire précédente.
https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201
C’est assez dégoûtant. Pourquoi Grit-lib est-il encore sous licence MIT ?
Réactions sur Hacker News
Le passage affirmant que, « après examen du code produit par le LLM, comme il a fallu des changements architecturaux assez vastes et profonds pour en faire une implémentation sous forme de bibliothèque et sûre en mémoire, nous avons conclu que ce codebase n’était pas une œuvre dérivée devant hériter de la GPL, et avons décidé de le publier sous licence MIT », semble être un point assez intéressant
Cela dit, si en traduisant un livre on commence aussi à changer l’intrigue et la personnalité des personnages, il devient flou de savoir à partir de quand ce n’est plus une œuvre dérivée. Je ne suis pas juriste, mais j’imagine que la jurisprudence sur les œuvres de création a déjà beaucoup traité ce type de frontière
Dans un climat où la notion de « propriété intellectuelle » continue de s’étendre comme aujourd’hui, admettre qu’un LLM a eu accès au code source de Git semble juridiquement fragiliser la position
Selon Jplag, la similarité maximale entre les codebases est inférieure à 1,8 %, cela a été fait de bonne foi, et j’estime que c’est aussi bénéfique pour l’ensemble de l’écosystème Git. Bien sûr, cela suppose que Grit devienne réellement utilisable, et ce n’est pas encore le moment de l’affirmer
Du point de vue du droit d’auteur, seul le premier point de cette discussion est pertinent. Grit est une implémentation écrite indépendamment d’un comportement compatible avec Git, et la similarité avec le code source de Git me semble négligeable
antirez a bien résumé la situation, et je suis globalement d’accord : https://antirez.com/news/162
Les personnes qui me connaissent et ont travaillé avec moi dans Git et la communauté open source depuis 20 ans savent que mon intention est de contribuer, de partager, et de favoriser l’innovation et l’apprentissage. Plusieurs des principaux auteurs du code source de Git sont mes amis, et je n’ai absolument aucune intention de voler quoi que ce soit à qui que ce soit. Je veux simplement rendre de bonnes idées plus largement utiles
https://news.ycombinator.com/item?id=47350424
Comme avec 1984 ou Torment Nexus, quelqu’un a pris comme mode d’emploi une idée qui aurait dû être reçue comme un avertissement
Par exemple, imaginons qu’on extraie le binaire de Goldeneye sur N64, qu’on le désassemble avec un LLM et qu’on lui fasse réécrire le tout dans un langage moderne de haut niveau. Est-ce que Nintendo dirait : « comme vous avez fourni beaucoup d’efforts, vous êtes sortis de notre licence » ? Bien sûr que non. Cela n’a aucun sens
Fournir le code source et lui faire produire un résultat dans un autre langage constitue clairement une œuvre dérivée. Pas besoin d’être avocat en propriété intellectuelle pour le comprendre
À l’inverse, si l’on donne seulement la documentation à Claude et qu’on lui demande de créer une implémentation compatible, serait-ce une œuvre dérivée soumise à la GPL ? Je pense probablement que oui, mais je n’en suis plus certain à 100 %, et je ne prendrais pas ce risque
Autre expérience de pensée : si quelqu’un prend cet arbre de sources « sous licence MIT », le donne à un autre LLM et lui demande de le sortir en C, que devient la licence ? Les manières de produire un hash SHA1 ou d’écrire un parseur de ligne de commande sont limitées, donc cela pourrait devenir assez similaire
Dans l’affaire Oracle v. Google aussi, c’était l’un des points centraux du litige. Google a soutenu avec succès que, comme il n’existe qu’un nombre limité de façons d’écrire certaines boucles, le simple fait d’avoir des boucles semblables à l’original ne constitue pas immédiatement une violation du droit d’auteur
Quoi qu’il en soit, adopter une telle position est vraiment excessif
Je ne comprends pas. Gitoxide existe déjà et c’est excellent
Il manque peut-être certaines choses, mais il serait plus simple d’ajouter à Gitoxide, qui est maintenu, les fonctionnalités réseau nécessaires en vibe coding que de brûler des tokens pour essayer de re-cloner Git en entier
Git veut des ajouts en Rust, et Gitoxide est un projet mené depuis des années, donc il a plus de chances d’être mieux maintenu qu’un clone improvisé en mode vibe qui « dit qu’il passe les tests »
Je ne suis pas opposé aux clones vibe en eux-mêmes s’il y a un cas utile, mais ici je ne vois pas l’avantage. Git est un outil que beaucoup de gens aiment, ce n’est pas une situation comme
vinext, né parce que les gens détestaient la dépendance fournisseur de Next.jsLa direction aussi devrait comprendre qu’annoncer « nous avons brûlé des milliers de dollars en tokens pour faire notre propre copie d’un logiciel aimé » n’a rien qui puisse être bien accueilli par la communauté, même en laissant de côté les débats sur le copyright et les licences
Ce n’est pas agréable de voir une œuvre qu’on aime être dupliquée sans aucun bénéfice. On a dépassé le stade de « l’expérience pour voir jusqu’où l’IA peut aller »
Il y a récemment eu une tentative intéressante d’ajouter davantage de fonctionnalités Git à Gitoxide via une boucle vibe : https://github.com/GitoxideLabs/gitoxide/pull/2538
Cela dit, je pense que ce projet peut avoir de la valeur avec encore un peu de travail. Cette annonce n’est pas un produit final, seulement une étape. Même au milieu du projet, nous n’étions pas sûrs que cela serait possible
Nous avons beaucoup appris et apprendrons encore, mais Gix, qui est une bibliothèque Git partielle de haute qualité, faite à la main et avec une vision claire, et Grit, qui se rapproche d’une implémentation complète créée en vibe mais reste un peu brouillonne en tant que bibliothèque Git LLM, peuvent tous deux avoir des usages utiles. Je pense qu’il vaut la peine d’explorer et d’investir dans les deux options pour le moment
Et je fais aussi partie de la direction impliquée, et j’ai fait pas mal de choses pour la communauté Git au fil des années. Dire que je veux « ma propre copie » n’a aucun sens
J’ai écrit le livre Pro Git(https://git-scm.com/book/en/v2) ainsi qu’avant cela le Git community book(https://schacon.github.io/gitbook/index.html), je les ai publiés en open source, j’ai créé le site officiel de Git(https://git-scm.com), j’ai cofondé GitHub, qui héberge presque tout l’open source mondial, et je promeus et soutiens l’écosystème Git depuis près de 20 ans
Il y a 15 ans, j’ai relancé et financé le développement de libgit2 ; on pourrait aussi prétendre que c’était une direction voulant sa « propre copie » de Git sous une licence plus permissive, mais cette affirmation serait tout aussi absurde
Ils ont sans doute jugé que gitoxide ne suffisait pas pour leur cas d’usage, ou que le coût pour l’étendre et l’améliorer était trop élevé
La sécurité mémoire et ce genre de choses, c’est bien, mais honnêtement je ne vois pas pour quel cas d’usage c’est fait
C’est pour montrer du développement agentique ? En plus de dix ans d’utilisation de Git, je n’ai jamais eu d’échec à cause d’un dépassement mémoire ou autre. Certains logiciels relèvent de la catégorie « c’est déjà largement assez bien », et je suis assez sûr que Git en fait partie
Même dans des équipes de plus de 20 développeurs avec beaucoup d’artefacts binaires, j’ai rarement atteint les limites de Git. Si on pousse vraiment Git à ses limites, il faut peut-être sortir de Git, et une réécriture en Rust n’aidera en rien. Donc je repose la question : pourquoi ?
Même pour faire de petites choses, il faut fork/exec un processus et communiquer via stdin/stdout. Sinon, il faut tout réimplémenter et gérer tous les cas particuliers
Par exemple, lire un objet est simple s’il s’agit d’un objet loose, mais c’est beaucoup plus difficile s’il est dans un packfile. Lire une référence, c’est-à-dire vérifier vers quel SHA pointe une branche, peut aussi impliquer un fichier loose, un packfile ou une reftable
Personne n’utilisera ça pour la CLI. Même si ça se stabilise, ce sera presque certainement toujours plus lent et pire sur tous les plans. En l’état, ce n’est même pas stable
On peut utiliser libgit2 ou Gitoxide, et ce sont deux projets que j’ai aidé à lancer ou que GitButler aide actuellement à faire avancer. Ils sont plus rapides et meilleurs sur presque tous les plans, mais leurs fonctionnalités ne sont pas complètes
Ce n’est pas fait pour les gens qui utilisent Git, mais pour ceux qui veulent créer des outils qui utilisent une partie de Git
Maintenant que tout le monde peut décider que son clone LLM n’est pas une œuvre dérivée, on dirait bien que les licences logicielles n’ont plus de sens
Récemment, Casey Muratori disait dans un contexte similaire que la poussée de Microsoft dans l’IA pouvait être liée au fait qu’ils possèdent une base de code ancienne et immense. Les vieilles grandes entreprises logicielles ont un avantage pour l’entraînement des modèles et peuvent apporter une valeur supplémentaire avec leur propriété intellectuelle
Mais à présent, cette propriété intellectuelle peut entrer dans les modèles et devenir accessible à tout le monde. Si une entreprise entraîne réellement un modèle sur sa propre propriété intellectuelle, alors n’importe qui pourrait implémenter cette API et y apposer une licence GPL
À partir de là, cela deviendra vraiment intéressant
C’est du plagiat de code GPL et du blanchiment de licence
Je peux comprendre l’idée de repartir à l’envers depuis la suite de tests, mais là ils ont littéralement lu le code source original : https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
On dirait que les utilisateurs de LLM vivent dans un autre monde, où tout ce qui n’est pas cloué au sol peut être volé puis présenté comme leur propre travail
C’est exactement ce que j’ai fait, par exemple, quand j’ai voulu faire fonctionner correctement la signature de commits SSH dans GitButler : https://blog.gitbutler.com/signing-commits-in-git-explained
Comme on peut le voir dans l’article, j’ai fouillé le code source C pour comprendre le comportement de référence, puis j’ai implémenté la même chose en Rust sans copier le code source
Il y a quelques similitudes entre le code Rust de Grit et celui de Git, mais ce sont surtout des éléments comme le traitement du temps, le formatage, ou des offsets d’octets nécessaires au parsing des packfiles. À mes yeux, il n’y a pas de copie directe de code
Pour en faire une base de code réentrante, sûre en mémoire et pensée comme une bibliothèque, l’approche est de toute façon tellement différente que la copie est en général peu utile
Mais les formats binaires de packfile ou de reftable ne sont pas documentés correctement, donc personne ne peut les deviner. Je le sais bien, puisque je suis probablement l’un des rares à avoir essayé de documenter le format binaire des packfiles : https://schacon.github.io/gitbook/7_the_packfile.html
Il faut forcément lire le code source. Avec cette définition, libgit2, Gitoxide et toutes les autres réimplémentations de Git seraient aussi du « blanchiment de licence », puisqu’elles ont dû consulter le code source de Git pour vérifier la spécification technique
Si vous trouvez dans Grit du code manifestement copié ligne par ligne, dites-le-moi. Je le remplacerai. Mais le code source de Git est la spécification de Git, et avec ou sans LLM, toutes les réimplémentations y sont contraintes si elles veulent être compatibles
Je ne comprends pas pourquoi d’autres détenteurs de propriété intellectuelle — par exemple ceux qui possèdent des logiciels propriétaires de valeur, ou de la musique, des films, voire des LLM eux-mêmes — ne se disent pas qu’ensuite les léopards viendront leur dévorer le visage
Cette érosion de la propriété intellectuelle doit cesser. Sinon, toute personne qui fait du travail intellectuel est complètement condamnée. Si cela ne concernait que les gens du FOSS, je craindrais déjà qu’ils soient sacrifiés avec l’eau du bain, mais c’est clairement un problème général
J’ai déjà utilisé auparavant l’analogie suivante : « C’est un peu comme faire un vœu à un génie. Il faut vraiment être très explicite sur les règles de base »
Avant, ça faisait davantage penser à un golem, mais avec le mode sabotage de Fable https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html, ça ressemble désormais clairement plus à un génie
Avant, je disais : « le modèle ne vous donne pas ce que vous voulez, il vous donne ce que vous avez demandé ». Maintenant, avec Fable, il ne donne même plus ce que vous voulez, donc je ne sais plus trop
À titre expérimental, c’est plutôt l’inverse qui m’intéresserait. Ces projets donnent généralement l’impression d’être des réécritures pour la “performance”, probablement parce que l’IA a fait baisser le coût
J’aimerais voir des choses absurdes mais amusantes, comme porter Quake III en Python, ou Kubernetes en Perl, voire Rails en Python
Il me semble que la majeure partie de Natural Selection 2 était en Lua, et c’était déjà il y a plus de dix ans
C’est plus lent, moins bien testé, et au final on a une implémentation incomplète de Git pour seulement 10 000 à 15 000 dollars
Au passage, pas mal de temps humain a aussi été gaspillé
Quelqu’un disait d’ailleurs qu’un autre groupe travaillait déjà sur un port Rust. Tout ce qu’on aurait pu accomplir en y consacrant cet argent et ces ressources de développement logiciel...
Il semble déjà démontré que l’IA peut porter quelque chose, à condition de ne pas trop tester en profondeur. Je trouve ce genre de travail de moins en moins utile. C’était peut-être amusant pour l’auteur, mais je ne vois pas en quoi cela aide les autres
Tout le mouvement RiiR est très clairement une tentative de s’éloigner de la GPL, une licence favorable aux utilisateurs
Je suis d’accord avec le début de « c’est une expérience assez amusante, et je pense qu’on peut en faire quelque chose de vraiment utile pour toute la communauté ». Les expériences, on peut tous en profiter.
En revanche, j’ai un désaccord philosophique avec la partie disant qu’« étant donné que ce n’est pas une bibliothèque liabile et réentrante, mais qu’elle repose sur la philosophie Unix consistant à chaîner des commandes plus simples, il est difficile de l’utiliser dans un processus de longue durée sans surcoût de fork/exec à chaque fois ».
C’est le seul passage de tout l’article qui explique le « pourquoi », mais on peut aussi considérer que l’approche Unix est une fonctionnalité, et qu’elle est aujourd’hui encore plus importante : https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic
Toute la phrase est essentielle : « étant donné que ce n’est pas une bibliothèque liabile et réentrante, mais qu’elle repose sur la philosophie “Unix” consistant à chaîner des commandes plus simples, il est difficile de l’utiliser dans un processus de longue durée sans surcoût de fork/exec pour chaque opération »
J’utilise Git depuis plus de 15 ans et je n’ai jamais eu un seul crash. Quel problème cherche-t-on exactement à résoudre ?
gcet le pruning provoquaient parfois des arrêts inattendus pendant un certain temps.Cela dit, la stabilité globale a vraiment été excellente. Mais je ne saurais pas répondre au « pourquoi ? » de cette réécriture en particulier.
Ils se lancent dans des choses de manière totalement inconsciente et naïve, et ont perdu la capacité de réfléchir par eux-mêmes. Le LLM qui pense à leur place ne leur dit pas que « faire X est une mauvaise idée ». Un LLM existe pour produire autant de tokens que possible pour son propriétaire
Ça vient du cofondateur de GitHub, donc probablement de quelqu’un qui sait très bien à quoi sert la GPL
Quels que soient les avantages et inconvénients juridiques, construire sur l’intégralité de la suite de tests d’un projet GPL3 puis relicencier le résultat en MIT, ce n’est pas agir de bonne foi envers les auteurs d’origine
C’est franchement répugnant et ça me donne envie d’éviter entièrement GitButler
On ne peut pas choisir une licence, puis ajouter après coup des conditions supplémentaires parce que le résultat ne nous plaît pas. C’est précisément ce que la licence GPL n’autorise pas explicitement