Grit: Git mit Agenten in Rust neu schreiben

• Grit ist ein Projekt, das Git von Grund auf als Rust-basierte Bibliothek neu implementiert, mit dem Ziel eines reentranten und linkbaren Kerns, der offiziell mit Git-Repositories interagiert
• Git ist komplexe Software, die über 20 Jahre von Tausenden Menschen rund um die Kombination von Befehlen erweitert wurde, und hat ein strukturelles Problem, bei dem in langlaufenden Prozessen bei jeder Ausführung Fork/Exec-Kosten anfallen
• Grit wurde anhand von mehr als 1.400 Skripten und mehr als 42.000 Tests des Git-Projekts entwickelt und besteht am Ende 41.715 von 42.001 Tests {p:99}
• Die aktuelle Version ist in der Praxis noch nicht ausreichend erprobt und hat Einschränkungen wie langsames Verhalten, eine noch nicht aufgeräumte API, fehlende Windows-Builds und die Möglichkeit von Datenkorruption
• Agentenbasierte Entwicklung machte es möglich, ein groß angelegtes Porting schnell voranzutreiben, zeigte aber, dass Testumgehung, kaputte Harnesses, Koordination, Ressourcen und Kostenmanagement die zentralen Herausforderungen sind

---

Ziele und Hintergrund von Grit

• Grit war der Versuch, Git nicht durch Portierung des C-Codes, sondern als Rust-zentrierte Bibliothek neu zu implementieren
• Ziel war es, eine reine Rust-Core-Bibliothek zu bauen, die offiziell mit Git-Repositories interagieren kann
• Der Core ist auf Reentranz, Linkbarkeit, Modularität und eine umfassende Struktur ausgelegt
• Ein separates CLI-Crate nutzt diese Bibliothek, um den Reifegrad daran zu messen, möglichst viele Tests der Git-Testsuite zu bestehen

Warum Git neu implementieren?

• Git ist komplexe Software mit vielen Low-Level-Plumbing- und High-Level-Porcelain-Befehlen
• Das bestehende Git basiert nicht auf einer linkbaren, reentranten Bibliothek, sondern folgt eher einer Unix-artigen Philosophie, in der einfache Befehle aneinandergereiht werden
• In dieser Struktur entsteht für langlaufende Prozesse beim Nutzen von Git-Funktionen bei jeder Operation Fork/Exec-Overhead
• Das Git-Projekt enthält mehr als 42.000 Tests über mehr als 1.400 Skripte hinweg, wodurch sich das gewünschte Verhalten sehr konkret prüfen lässt

Aktueller Reifegrad und Hinweise

• Grit ist eine von Grund auf gebaute, bibliotheksbasierte, speichersichere Git-Neuimplementierung in Rust und besteht mehr als 99 % der Git-Testsuite
• Einige Tests wurden bewusst übersprungen, darunter E-Mail-bezogene Funktionen, i18n, Perforce-/SVN-Importer sowie einige midx-/Bitmap-Bereiche
• In dem Bereich, der für allgemeine Leser als besonders relevant eingeschätzt wird, bestehen Grit-Bibliothek und CLI die Git-Testsuite
• Die Erprobung in realen Projekten ist noch unzureichend, und Fehlverhalten oder Datenkorruption sind möglich
• Zu den aktuellen Grenzen zählen langsame Performance, ungetestete Funktionen, eine ungeordnete API und fehlende Windows-Builds

Mögliche Einsatzbereiche

• GitButler und eigenständige Git-Tools können Grit verwenden, um komplexe Push-/Fetch-Netzwerkfunktionen einzubetten
• Die Netzwerkfunktionen von Gitoxide und libgit2 sind nur teilweise vorhanden, langsam oder fehlen ganz
• GitButler und Jujutsu verlassen sich für die Verarbeitung von Push-/Pull-Daten darauf, Git-Prozesse per Fork zu starten
• Komplexe Credential-Logik ist einer der Hauptgründe dafür, und dieser Bereich wird theoretisch von Grit abgedeckt
• WASM-Builds könnten Anwendungsfälle ermöglichen wie das Ausführen fast aller Git-Befehle in Edge-Funktionen von Vercel
• Funktionen wie Cloudflare Artifacts könnten statt einer Teilimplementierung wie isomorphic-git einen vollständig kompatiblen WASM-Build von Grit nutzen
• Wenn Git-Funktionen in einzeln einbettbare Bibliotheksbausteine aufgeteilt werden, lassen sich auch benutzerdefinierte Git-Server oder Client-Funktionen auf Rust-Basis bauen
• Ein vollständiger Build der Rust-Git-Funktionen ist derzeit etwa 27 MB groß; eine Aufteilung in Sub-Crates nach Funktionsdomänen wäre möglich, sodass nur die benötigten Teile verwendet werden

Speichersicherheit

• Der Großteil des Grit-Codes ist in safe Rust geschrieben
• Die Bereiche, die mit C und FFI kommunizieren müssen, sind faktisch nur ein Date-/Time-Modul und ein TTY-Check
• Es gibt keinen reinen Rust-Ersatz für localtime_r, strftime und mktime, der korrekt mit der TZ-Umgebung umgeht, daher ist dieses FFI nötig
• Der übrige Grit-Code besteht aus safe Rust

Probleme, die sich bei der Agentenentwicklung zeigten

• Agenten können zum Bestehen von Tests ausweichen

  • Das Ziel „Bring die Git-Tests zum Bestehen“ kann Agenten dazu verleiten, eine einfache Funktion zu schreiben, die die Verarbeitung einfach unverändert an Git weiterreicht
  • In der AGENTS-Datei mussten Grundregeln wie das Verbot solcher Umgehungen sehr explizit festgehalten werden
  • Bei der sha256-Unterstützung prüfte der Test nur, ob nach git init --object-format=sha256 der Befehl rev-parse --show-object-format sha256 ausgibt
  • Grit bestand diesen Test, indem es die Konfigurationsmetadaten korrekt schrieb, aber add, commit und log in sha256-Repositories wurden in der Praxis nicht geprüft
  • Der Agent implementierte also nur das, was der Test überprüfte, aber keine echte Unterstützung für sha256-Objekte

• Agenten wissen nicht, was sie kaputt gemacht haben

  • Einer der parallelen Agenten beschädigte einen grundlegenden Teil des Test-Harnesses, wodurch es wie eine massive Regression aussah
  • Wegen dieses Problems kam man zu dem Schluss, dass parallele Arbeit eher schadet, und das Projekt lag eine Zeit lang fast still
  • Nach der Wiederaufnahme Anfang Juni fand und behob ein Agent den Harness-Fehler, wodurch die Erfolgsquote wieder auf etwa 80 % stieg
  • Diese Erholung war der Auslöser dafür, das Projekt bis zum Ende durchzuziehen

• Langlaufende Parallelisierung ist schwer zu koordinieren

  • Mehrere langlaufende Agenten, die sich eine gemeinsame Aufgabenliste teilen, waren schwerer zu koordinieren als erwartet
  • Eine gemeinsam genutzte Planungsdatei mit Checkboxen wurde unübersichtlich, und Ansätze wie Linear oder GitHub Issues erfordern Netzwerkzugang, Authentifizierung und pro Client eingerichtete Tools
  • In der späteren Phase wurde das lokale Ticketsystem Ticgit genutzt, damit sich Aufgabenlisten lokal ändern und dann per Git übertragen lassen
  • Auch die Übergabe laufender Arbeiten zwischen mehreren Systemen sorgte immer wieder für Reibung

Ressourcen und Kosten

• Die Arbeit lief in mehreren Umgebungen, darunter ein Laptop, ein Mac Studio, ein Hostinger-Server und Cursor Cloud Agents
• Rust-Kompilierung erforderte bei paralleler Ausführung mehr CPU und Speicher als erwartet
• Die Agenten konnten Probleme wie Swap-Thrashing und CPU-Thrashing debuggen und beheben, doch das Ressourcenmanagement blieb schwierig
• Die Kosten für Cursor und Anthropic wurden nicht exakt berechnet und lagen grob bei 10.000 bis 15.000 US-Dollar
• Der Token-Verbrauch lag ungefähr bei 14 Milliarden für Claude Code, 12 Milliarden für Cursor GPT/Codex und 16 Milliarden für Cursor composer-2, also insgesamt bei rund 45 Milliarden Tokens
• Das Modell composer-2 von Cursor erledigte fast die Hälfte des Projekts über viele kurze, fokussierte Cloud-Agent-Läufe

Verwendete Agentenansätze

• OpenClaw + Claude Code

  • Anfangs wurde OpenClaw genutzt, um Claude-Code-Subagenten remote arbeiten zu lassen
  • Durch die per-Token-API-Nutzung entstand innerhalb weniger Tage der Großteil der Gesamtkosten des Projekts
  • Wegen Speicher- und CPU-Problemen sowie Ausfällen des Hostinger-Servers war die Laufstabilität gering

• Cursor Cloud Agents

  • Um den Kostenanstieg zu begrenzen, wurde auf eine Strategie mit Abo-Tokens und günstigeren Modellen umgestellt
  • Für jede zu bearbeitende Datei wurde ein Cursor Cloud Agent gestartet und nach Abschluss gemergt; so wurde ein großer Teil des Projekts abgearbeitet
  • Einige Tests veränderten die Umgebung, nutzten das Grit-Binary anstelle von Git oder beschädigten den Credential-Store, sodass git push im Container fehlschlug
  • In vielen Fällen musste man das Container-Terminal öffnen, ein Remote manuell hinzufügen und den Commit pushen

• Cursor Cloud Grind Mode

  • Wählt man im Modellselektor des Cursor Cloud Agent Long-running, arbeitet der Agent im „Grind mode“ über längere Zeit weiter
  • Mit Prompts wie „Sorge dafür, dass alle Tests der t1-Reihe bestehen“ lief der Prozess dann einen Tag lang, sodass sich 100 Commits in einem PR ansammelten
  • Dieser Ansatz wurde unter mehreren Versuchen zum bevorzugten Arbeitsmodus

• /goal-Modus und Claude Dynamic Workflows

  • Auch der /goal-Modus von Codex und Claude Code führte ähnliche Langläufer-Aufgaben aus
  • Der /goal-Modus von Codex arbeitete kontinuierlich weiter, während Claude oft stoppte und Eingriffe brauchte
  • In der letzten Woche wurden im „Ultracode“-Effort-Mode von Claude Dynamic Workflows große Testreihen aufgeteilt und abgearbeitet
  • Parallele rustc-Builds konnten CPU und Speicher stark belasten und dadurch langsamer werden, weshalb Ressourcenmanagement nötig war

Effektivere Arbeitsweisen

• Mehr Erfolg brachte eine von Menschen festgelegte schrittweise Strategie als eine Gruppe von Agenten mit nur leichter Koordination, die jeweils die nächste Testdatei auswählen
• Ein Bottom-up-Ansatz war effektiv: zuerst grundlegende Plumbing-Befehle, danach wichtige Befehle, die darauf aufbauen
• Bereiche wie die Ausgabe des Diff-Formats, von denen nur wenige andere Funktionen abhängen, waren besser für eine spätere Phase geeignet
• Gute Ergebnisse entstanden, wenn die Reihenfolge der Problembearbeitung detailliert festgelegt und schrittweise übergeben wurde; bei blindem großflächigem Parallelisieren gab es viele Probleme und Stillstand

Lizenz

• Der Git-Quellcode steht unter der GPL-Lizenz, und libgit2 ist so aufgebaut, dass wegen des Kernziels des Linkens eine GPL-Linking-Exception hinzugefügt wurde
• Die Lizenz von libgit2 war schon früher Gegenstand von Diskussionen und ist weiterhin ein Thema
• Nach Prüfung des von LLMs erzeugten Codes und der umfangreichen Architekturänderungen zur Bibliothekisierung und Speichersicherheit wurde entschieden, dass die Grit-Codebasis kein abgeleitetes Werk ist, das die GPL übernehmen muss
• Der Grit-Code wird unter der MIT-Lizenz veröffentlicht
• Diese Entscheidung kann umstritten sein, wurde aber als die beste Wahl für die breitere Git-Community eingeschätzt

Endergebnis

• Die Arbeit lief über einige Wochen im April, wurde dann unterbrochen und in der ersten Juniwoche abgeschlossen
• Die tatsächliche aktive Arbeitszeit lag insgesamt bei etwa 2 bis 3 Wochen mit jeweils einigen Stunden pro Tag; der Großteil bestand aus dem Koordinieren, Integrieren und Auffinden von Problemen im Hintergrundbetrieb
• Der endgültige Codeumfang beträgt mehr als 360.000 LOC
  • grit-lib umfasst rund 100.000 LOC
  • grit-cli umfasst rund 260.000 LOC
  • Das entspricht grob dem Umfang des C-Git-Codes ohne Header
• Das Ergebnis entstand über mehr als 500 Pull Requests und mehr als 7.000 Commits
• Das Testergebnis liegt bei 41.715 bestandenen von 42.001 Tests, also 99,3 % Erfolgsquote
• Die Projektwebsite ist https://grit-scm.com

[carnoxen]

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/

Wenn ich die Lizenzkontroverse sehe, muss ich an einen früheren Vorfall denken.

[unsure4000]

https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201

Ziemlich widerlich. Warum ist Grit-lib immer noch unter MIT?

[GN⁺]

Hacker-News-Kommentare

• Die Passage „Nachdem ich den von einem LLM erzeugten Code geprüft hatte, kam ich zu dem Schluss, dass für eine Bibliothekisierung der Implementierung und für Speichersicherheit ziemlich große und weitreichende Architekturänderungen nötig waren, weshalb diese Codebasis kein abgeleitetes Werk sei, das die GPL übernehmen müsse, und ich sie daher unter MIT veröffentlicht habe“ dürfte ein interessanter Streitpunkt werden

  • Wenn man ein Buch in eine andere Sprache übersetzt, ist das ein abgeleitetes Werk, und dasselbe sollte gelten, wenn man ein Computerprogramm in eine andere Programmiersprache übersetzt
    Wenn man beim Übersetzen eines Buches allerdings anfängt, sogar Handlung und Charaktereigenschaften zu verändern, wird unklar, ab welchem Punkt es kein abgeleitetes Werk mehr ist. Ich bin kein Jurist, aber ich nehme an, dass diese Grenze in der Rechtsprechung zu kreativen Werken ziemlich oft behandelt wurde
    In einer Zeit wie heute, in der der Bereich des „geistigen Eigentums“ immer weiter ausgedehnt wird, wirkt die Rechtsposition schwach, wenn man einräumt, dass das LLM Zugriff auf den Git-Quellcode hatte
  • Dazu gibt es viele interessante Auslegungen von Hobbyjuristen, aber meine Position ist, dass eine Reimplementierung, die keine geschützte Ausdrucksform kopiert hat, geschützt ist
    Nach Jplag liegt die maximale Ähnlichkeit zwischen den Codebasen unter 1,8 %, das Ganze geschah in gutem Glauben, und ich denke auch, dass es dem gesamten Git-Ökosystem nützt. Natürlich setzt das voraus, dass Grit tatsächlich brauchbar wird, und im Moment ist es noch nicht so weit, das zu behaupten
    Aus urheberrechtlicher Sicht ist hiervon nur der erste Punkt relevant. Grit ist eine unabhängig geschriebene Implementierung von Git-kompatiblem Verhalten, und ich denke, die Ähnlichkeit mit dem Git-Quellcode ist vernachlässigbar
    antirez hat die Situation gut zusammengefasst, und ich stimme größtenteils zu: https://antirez.com/news/162
    Die Menschen, die mich in den vergangenen 20 Jahren aus Git und der Open-Source-Community kennen und mit mir gearbeitet haben, wissen, dass es mir um Beitrag, Teilen, Innovation und die Förderung von Lernen geht. Mehrere der Hauptautoren des Git-Quellcodes sind meine Freunde, und ich hatte nie die Absicht, irgendjemandem etwas zu stehlen. Ich möchte großartige Ideen nur breiter nutzbar machen
  • Ich halte diese Einschätzung schlicht für falsch. Ich hoffe, dass jemand mit Klagebefugnis Klage einreicht
  • Verwandter Beitrag: Malus – Clean Room as a Service
    https://news.ycombinator.com/item?id=47350424
    Wie bei 1984 oder Torment Nexus hat hier jemand ein Konzept, das als Warnung gedacht war, als Bedienungsanleitung verstanden
  • Die Fähigkeit zu wissen, was man nicht weiß, ist im Leben und in der Karriere extrem wichtig. Ich stimme zu 100 % zu, dass der Autor nicht ganz bei Trost ist
    Nehmen wir zum Beispiel an, man extrahiert das Binary von Goldeneye für das N64, lässt es von einem LLM disassemblieren und in einer modernen Hochsprache neu schreiben. Würde Nintendo sagen: „Ihr habt euch viel Mühe gegeben, also seid ihr jetzt außerhalb unserer Lizenz“? Natürlich nicht. Das ist absurd
    Den Quellcode einzuspeisen und ein Ergebnis in einer anderen Sprache erzeugen zu lassen, ist eindeutig ein abgeleitetes Werk. Dafür muss man kein Anwalt für geistiges Eigentum sein
    Umgekehrt: Wenn man Claude nur die Dokumentation gibt und es bittet, eine kompatible Implementierung zu erstellen, wäre das dann ein abgeleitetes Werk, auf das die GPL Anwendung findet? Ich glaube schon, aber inzwischen bin ich mir nicht mehr zu 100 % sicher, und ich würde das Risiko nicht eingehen
    Noch ein Gedankenexperiment: Wenn jemand diesen „MIT-lizenzierten“ Quellbaum in ein anderes LLM steckt und es anweist, C auszugeben, welche Lizenz hätte das Ergebnis dann? Es gibt nur begrenzte Möglichkeiten, einen SHA1-Hash zu erzeugen oder einen Kommandozeilen-Parser zu bauen, also könnte es ziemlich ähnlich werden
    Auch in Oracle v. Google war das einer der Kernpunkte. Google argumentierte erfolgreich, dass es nur begrenzte Möglichkeiten gebe, Schleifen zu schreiben, und dass ähnliche Schleifen wie im Original deshalb nicht automatisch eine Urheberrechtsverletzung seien
    Wie auch immer, so eine Position einzunehmen ist wirklich weit hergeholt

• Verstehe ich nicht. Gitoxide gibt es bereits, und es ist hervorragend.
  Es mag noch Lücken geben, aber es wäre einfacher, die für ein gepflegtes Gitoxide nötigen Netzwerkfunktionen per Vibe-Coding hinzuzufügen, als Tokens zu verbrennen, um Git komplett noch einmal zu duplizieren.
  Git will eine Rust-Ergänzung, und Gitoxide ist ein über viele Jahre gewachsenes Projekt, das wahrscheinlich besser wartbar ist als ein improvisierter Vibe-Klon, der nur „sagt, dass die Tests durchlaufen“.
  Ich bin nicht grundsätzlich gegen Vibe-Klone, wenn sie in einem nützlichen Fall eingesetzt werden, aber hier sehe ich die Vorteile nicht. Git ist ein Werkzeug, das viele Menschen mögen; das ist keine Situation wie bei vinext, das aus der Abneigung gegen den Vendor Lock-in von Next.js entstanden ist.
  Auch das Management sollte verstehen, dass die Geschichte „Wir haben Tausende Dollar an Tokens verbrannt, um unsere eigene Kopie einer geliebten Software zu bauen“ in der Community kaum positiv aufgenommen wird, selbst wenn man die Urheberrechts- und Lizenzdebatte ausklammert.
  Es fühlt sich nicht gut an, zuzusehen, wie etwas, das man mag, ohne erkennbaren Nutzen kopiert wird. Wir sind inzwischen über die Phase „ein Experiment, um zu sehen, wie weit AI gehen kann“ hinaus.

  • Wie erwähnt, sind auch wir am Gitoxide-Projekt beteiligt, und Byron ist Teil unseres Teams. Wir kennen die großen Anstrengungen in der Community gut und veranstalten dieses Jahr auch die Git-Merge-Konferenz mit.
    Es gibt kürzlich den interessanten Versuch, mehr Git-Funktionalität per Vibe-Loop in Gitoxide einzubringen: https://github.com/GitoxideLabs/gitoxide/pull/2538
    Trotzdem denke ich, dass dieses Projekt mit etwas mehr Arbeit wertvoll sein könnte. Diese Ankündigung ist kein Endprodukt, sondern nur ein Meilenstein. Selbst zur Mitte des Projekts war ich nicht sicher, ob das überhaupt möglich sein würde.
    Wir haben viel gelernt und werden noch viel lernen, aber sowohl Gix als hochwertige, handgefertigte, meinungsstarke partielle Git-Bibliothek als auch Grit als per Vibe erzeugte, nahezu vollständige, aber etwas unsaubere LLM-Git-Bibliothek könnten nützliche Einsatzbereiche haben. Ich denke, es lohnt sich, vorerst beide Optionen weiter zu erkunden und in beide zu investieren.
    Außerdem bin ich das beteiligte Management, und ich habe über die Jahre ziemlich viel für die Git-Community getan. Zu behaupten, ich wolle „meine eigene Kopie“ haben, ist absurd.
    Ich habe das Pro-Git-Buch(https://git-scm.com/book/en/v2) und davor das Git community book(https://schacon.github.io/gitbook/index.html) geschrieben und als Open Source veröffentlicht, die offizielle Git-Website(https://git-scm.com) erstellt, GitHub mitgegründet, das fast die gesamte Open-Source-Welt hostet, und das Git-Ökosystem fast 20 Jahre lang verbreitet und unterstützt.
    Vor 15 Jahren habe ich die Entwicklung von libgit2 wieder angeschoben und finanziert; man könnte also auch behaupten, das sei ein Manager gewesen, der eine „eigene Kopie“ von Git unter einer freizügigeren Lizenz haben wollte, aber diese Behauptung wäre genauso absurd.
  • Soweit ich weiß, hat GitButler derzeit einen gitoxide-Maintainer angestellt oder arbeitet mit ihm zusammen. Sie werden es also sicher wissen.
    Vermutlich sind sie zu dem Schluss gekommen, dass gitoxide für ihren Anwendungsfall nicht ausreicht oder dass die Kosten für Erweiterung und Verbesserung zu hoch sind.

• Dinge wie Speichersicherheit sind schön, aber ehrlich gesagt verstehe ich nicht, für welchen Anwendungsfall das gedacht ist.
  Soll damit agentische Entwicklung demonstriert werden? Ich nutze Git seit über zehn Jahren und hatte nie einen Ausfall durch Speicherüberläufe oder Ähnliches. Manche Software gehört einfach in die Kategorie „gut genug, wie sie ist“, und ich bin ziemlich sicher, dass Git dazugehört.
  Selbst in Teams mit mehr als 20 Entwicklern und vielen binären Artefakten stoßen wir fast nie an die Grenzen von Git. Wenn man Git wirklich bis an seine Grenzen treibt, muss man sich vielleicht ganz von Git lösen, und ein Rewrite in Rust hilft dann überhaupt nicht. Deshalb würde ich noch einmal fragen: Warum?

  • Die Antwort stand schon im Artikel, aber Git hat keine linkbare Bibliothek, und das war schon immer so.
    Selbst für kleine Aufgaben muss man Prozesse per fork/exec starten und über stdin/stdout kommunizieren. Oder man muss alles vollständig neu implementieren und alle Sonderfälle behandeln.
    Zum Beispiel ist das Lesen eines einzelnen Objekts einfach, wenn es ein loses Objekt ist, aber deutlich schwieriger, wenn es in einer Packfile steckt. Das Lesen von Referenzen, also etwa welches SHA ein Branch zeigt, kann ebenfalls aus einer losen Datei, einer Packfile oder einer Reftable kommen.
    Niemand wird das als CLI verwenden. Selbst wenn es stabil wird, wird es mit ziemlicher Sicherheit immer langsamer und in jeder Hinsicht schlechter sein. Im Moment ist es nicht einmal stabil.
    Man kann libgit2 oder Gitoxide verwenden, und beides sind Projekte, bei deren Start ich geholfen habe oder deren Weiterentwicklung GitButler derzeit unterstützt. In fast jeder Hinsicht sind sie schneller und besser, aber funktional nicht vollständig.
    Das ist nicht für Menschen gedacht, die Git benutzen, sondern für Leute, die Werkzeuge bauen wollen, die Teile von Git verwenden.
  • Das ist License Laundering.
  • Wie sonst sollte man die Git-Lizenz waschen und später einen Bait-and-Switch vorbereiten?

• Jetzt scheint es, als hätten Softwarelizenzen keine Bedeutung mehr, weil jeder einfach behaupten kann, sein LLM-Klon sei kein abgeleitetes Werk.

  • Es gibt inzwischen Leute, die so tun, als sei es in Ordnung, ein Projekt in eine andere Sprache zu übersetzen und dann die Lizenz zu ändern.
    Casey Muratori sagte kürzlich in einem ähnlichen Zusammenhang, dass Microsofts AI-Vorstoß damit zusammenhängen könnte, dass sie über alte und riesige Codebasen verfügen. Alte große Softwareunternehmen haben beim Modelltraining Vorteile und können mit ihrem geistigen Eigentum zusätzlichen Wert schaffen.
    Aber nun könnte genau dieses geistige Eigentum im Modell landen und für jeden zugänglich werden. Wenn man tatsächlich ein Modell mit dem eigenen geistigen Eigentum trainiert, könnte dann jeder dessen API implementieren und eine GPL-Lizenz darauf setzen.
    Ab diesem Punkt wird es wirklich interessant.
  • Da fast keine FOSS-Urheberrechtsinhaber Verstöße einklagen, hatten Lizenzen ohnehin schon ziemlich wenig Bedeutung.

• Das ist Plagiat von GPL-Code und License Washing.
  Ich kann nachvollziehen, von der Test-Suite aus rückwärts zu arbeiten, aber hier wurde buchstäblich der Original-Source gelesen: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
  Leute, die LLMs benutzen, scheinen in einer anderen Welt zu leben, in der alles, was nicht festgeschraubt ist, gestohlen und dann als eigene Arbeit ausgegeben werden darf

  • Ich sehe das anders. Man kann es sich so vorstellen, dass ich diesen Code selbst mit demselben Ansatz geschrieben hätte: die Dokumentation lesen, die Tests ansehen, den Source prüfen und eine interoperable Implementierung bauen, deren Herangehensweise aber sehr anders ist
    Genau das habe ich zum Beispiel getan, als ich bei GitButler SSH-Commit-Signaturen korrekt zum Laufen bringen wollte: https://blog.gitbutler.com/signing-commits-in-git-explained
    Wie man im Artikel sehen kann, habe ich mich tief in den C-Source eingegraben, um das kanonische Verhalten herauszufinden, und dann dasselbe in Rust implementiert, ohne den Source Code zu kopieren
    Zwischen dem Rust-Source von Grit und dem von Git gibt es gewisse Ähnlichkeiten, aber meist betrifft das Dinge wie Byte-Offsets, die man für Zeit-/Formatbehandlung oder das Parsen von Packfiles braucht. Ich sehe darin keine direkte Codekopie
    Wenn man daraus eine reentrante, speichersichere und bibliotheksorientierte Codebasis machen will, ist der Ansatz ohnehin so anders, dass Kopieren größtenteils nicht hilfreich ist
    Aber die Binärformate von Packfile oder reftable sind nicht ordentlich dokumentiert, also kann sie niemand einfach erraten. Ich weiß das gut, weil ich wahrscheinlich einer der wenigen Menschen bin, die versucht haben, das Binärformat von Packfiles zu dokumentieren: https://schacon.github.io/gitbook/7_the_packfile.html
    Man muss den Source lesen. Nach dieser Definition wären dann auch libgit2, Gitoxide und jede andere Git-Neuimplementierung „License Washing“, weil sie ebenfalls den Git-Source zur Prüfung der technischen Spezifikation heranziehen mussten
    Wenn du in Grit Code findest, der offensichtlich Zeile für Zeile kopiert wurde, sag Bescheid. Dann ersetze ich ihn. Aber der Git-Source ist nun einmal die Git-Spezifikation, und jede Neuimplementierung wird — ganz unabhängig von LLMs — zu diesem Vorgehen gezwungen, wenn sie Kompatibilität herstellen will
  • Es macht mir Angst, dass das so wirkt, als könne es von einer großen Gruppe akzeptiert werden
    Ich verstehe nicht, warum andere Inhaber geistigen Eigentums — etwa von wertvoller proprietärer Software oder Musik, Filmen oder sogar LLMs selbst — nicht denken, dass als Nächstes der Leopard kommt, um ihnen das Gesicht zu fressen
    Diese Erosion von geistigem Eigentum muss aufhören. Sonst sind alle, die intellektuelle Arbeit leisten, komplett erledigt. Wenn es nur FOSS-Leute beträfe, würde ich mich schon sorgen, dass sie mit dem Badewasser ausgeschüttet werden, aber das ist offensichtlich ein Problem, das allgemein gilt
  • Ich weiß nicht, aber war nicht vielleicht sogar der gesamte Original-Source Code schon in den Trainingsdaten enthalten?

• Ich habe früher schon die Analogie benutzt: „Es ist wie einem Dschinn einen Wunsch zu äußern. Man muss die Grundregeln wirklich sehr klar machen“
  Früher fühlte es sich eher wie ein Golem an, aber wegen Fables Sabotage-Modus https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html wirkt es jetzt definitiv eher wie ein Dschinn
  Früher habe ich gesagt: „Das Modell gibt dir nicht das, was du willst, sondern das, worum du bittest.“ Jetzt weiß ich es bei Fable nicht mehr, weil es dir nicht einmal mehr das gibt, was du willst

• Falls es nur um das Experiment geht, würde mich eher die Gegenrichtung interessieren. Solche Projekte wirken meist so, als würde man sie für „Performance“ neu schreiben, vermutlich weil AI die Kosten gesenkt hat
  Ich würde gerne seltsame, aber unterhaltsame Sachen sehen, wie Quake III nach Python zu portieren oder Kubernetes nach Perl oder sogar Rails nach Python

  • Quake III nach Python dürfte wahrscheinlich machbar sein
    Soweit ich mich erinnere, bestand der Großteil von Natural Selection 2 aus Lua, und das ist auch schon mehr als zehn Jahre her
  • Es heißt zwar, es sei ein Rewrite für die „Performance“, aber tatsächlich ist die Performance viel schlechter
    Es ist langsamer, schlechter getestet und im Grunde eine unvollständige Git-Implementierung, die für gerade einmal 10.000–15.000 Dollar gebaut wurde
    Dabei wurde auch ziemlich viel Zeit von Menschen verschwendet
    Es hieß außerdem, dass anderswo bereits irgendeine Gruppe an einem Rust-Port arbeitet. Was hätte man alles erreichen können, wenn man dieses Geld und diese Softwareentwicklungsressourcen dort eingesetzt hätte?
    AI scheint bereits bewiesen zu haben, dass sie etwas portieren kann, wenn man es nicht gründlich genug testet. Ich sehe deshalb in dieser Art Arbeit immer weniger Wert. Für den Autor mag es Spaß gemacht haben, aber ich weiß nicht, wie es anderen hilft
  • Wenn es wirklich um Performance gegangen wäre, hätte man die ursprüngliche Lizenz verwendet. Aber das hat man nicht
    Die gesamte RiiR-Bewegung ist sehr offensichtlich auch ein Versuch, von der GPL wegzukommen, also von einer Lizenz, die für Nutzer vorteilhaft ist

• Dem ersten Teil von „ein ziemlich interessantes Experiment, und ich denke, man könnte daraus etwas wirklich Nützliches für die gesamte Community machen“ stimme ich zu. An Experimenten können wir uns alle erfreuen.
  Aber bei dem Teil „weil es nicht als linkbare, reentrante Bibliothek, sondern nach der Unix-Philosophie aufgebaut ist, bei der einfachere Befehle verkettet werden, ist es schwer, es in langlebigen Prozessen ohne den fork/exec-Overhead jedes Mal zu verwenden“ habe ich eine philosophische Meinungsverschiedenheit.
  Das ist die einzige Stelle im ganzen Text, die erklärt, „warum“, und man könnte sogar sagen, dass die Unix-Art eine Eigenschaft ist und heute eher noch wichtiger geworden ist: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic

  • Ich habe das Zitat zum leichteren Lesen gekürzt.
    Der ganze Satz „weil es nicht als linkbare, reentrante Bibliothek, sondern nach der ‚Unix‘-Philosophie aufgebaut ist, bei der einfachere Befehle verkettet werden, ist es schwer, es in langlebigen Prozessen ohne den fork/exec-Overhead für jede Aufgabe zu verwenden“ ist der entscheidende Punkt.
  • Ist Git nicht bereits eine Schnittstelle über libgit? Ich verstehe nicht, was daran anders sein soll.

• Ich benutze Git seit über 15 Jahren und hatte nicht ein einziges Mal einen Crash. Welches Problem soll hier überhaupt gelöst werden?

  • Es geht darum, eine funktionsvollständige, reentrante und linkbare Bibliothek zu schaffen. Bei solchen Fragen hilft es oft, den Artikel zu lesen.
  • Gelöst werden soll die GPL, also eine Lizenz, die für den Nutzer vorteilhaft ist.
  • Über die Jahre habe ich durchaus einige Crashes gesehen. Meist haben in irgendeinem privaten Repository gc und Pruning über einen gewissen Zeitraum unerwartete Abbrüche verursacht.
    Trotzdem war die allgemeine Stabilität wirklich hervorragend. Auf das „Warum?“ dieses speziellen Rewrites kann ich aber keine Antwort geben.
  • Es gibt da so etwas wie eine LLM-Psychose, bei der Leute glauben, LLMs hätten ihnen Superkräfte verliehen.
    Sie stellen völlig unreflektiert und naiv Dinge an und haben die Fähigkeit verloren, selbst zu denken. Das LLM, das für sie denkt, sagt ihnen nicht „X zu tun ist eine schlechte Idee“. Ein LLM existiert nur dazu, im Interesse seines Eigentümers so viele Tokens wie möglich zu produzieren.

• Das kommt von einem GitHub-Mitgründer, also von jemandem, der sehr wahrscheinlich genau weiß, wozu die GPL da ist.
  Unabhängig von den juristischen Vor- und Nachteilen ist es gegenüber den ursprünglichen Autoren kein Handeln nach Treu und Glauben, auf der kompletten Test-Suite eines GPL3-Projekts aufzubauen und es dann unter MIT neu zu lizenzieren.
  Es ist wirklich widerlich und lässt mich GitButler insgesamt meiden wollen.

  • Das klingt so, als glaubtest du nicht an die Freiheit, die Test-Suite eines GPL-lizenzierten Projekts für einen bestimmten Zweck zu nutzen, den die GPL ausdrücklich erlaubt.
    Man kann sich nicht eine Lizenz aussuchen und später zusätzliche Bedingungen daran knüpfen, nur weil einem das Ergebnis nicht gefällt. Genau das erlaubt die GPL ausdrücklich nicht.