Wenn ich mein eigenes GitHub bauen könnte

 (matduggan.com)
5 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Moderne Forge-Plattformen wie GitHub, GitLab und Gitea teilen zwar dasselbe GitHub-artige Modell, aber der eigentliche Kern der Arbeit findet oft stärker in Forge-Funktionen wie PRs, Actions, Issues und Releases statt als in git selbst
  • Eine neue Forge sollte erzwingbare Pre-Commit-Hooks remote ausführen können, die Feedback nicht erst nach dem Commit, sondern schon vor dem Push geben, um wiederholte Commits wie Feature, fix, actually fix oder asdfasdf zu verringern
  • PR-Freigaben sollten über die reine Zweiteilung in Genehmigung/Ablehnung hinausgehen, wie bei Gerrit schwache Zustimmung und Markierungen für spätere erneute Prüfung unterstützen und kleine Änderungen, bei denen der Autor Maintainer ist und ein LLM ein geringes Risiko erkennt, flexibler durchlassen können
  • Stacked PRs sollten eine erstklassige Funktion von Forge und VCS sein, und das lokale Repository sollte nicht nur den Code, sondern den vollständigen Zustand des Repositories einschließlich PR-Freigaben und Issues abbilden
  • Die gewünschte Kombination wäre JJ als VCS, eine neue Forge, die in kleinen Einheiten hostbar ist, und Actions mit Unterstützung für Signaturen, SHA und Offline-Ausführung; im Zeitalter, in dem das riesige GitHub-Forge die Standardeinstellung ist, gibt es aber noch keine klare Alternative

Probleme moderner Forge-Plattformen

  • GitHub, GitLab und Gitea folgen trotz Detailunterschieden fast demselben Designmodell und ähneln eher einer Übernahme des von GitHub geprägten Branchenmusters durch andere Werkzeuge
  • Der Großteil der Funktionen heutiger Forge-Plattformen hat fast nichts direkt mit git selbst zu tun, und die Clients sind von der tatsächlichen Nutzungspraxis entkoppelt
  • git ist ein verteiltes Versionskontrollsystem, das gut zu Umgebungen wie der Kernel-Entwicklung passt und für einen Workflow mit hohem Vertrauensniveau geeignet ist, bei dem Patches per E-Mail an Maintainer geschickt werden, diese ihren Bereich verwalten und über Merges entscheiden
  • In den meisten Unternehmen ist git aber eher ein Mittel, um Code aus einem auf einer zentralen Forge gespeicherten Repository zu pullen und zu pushen, während die wichtigen Arbeiten in der Forge stattfinden
    • Pull Requests sind ein Mittel geworden, um das Vier-Augen-Prinzip durchzusetzen
    • GitHub Actions führen in Pull Requests Tests und Linting aus, um Funktionalität und die Einhaltung organisatorischer Anforderungen zu prüfen
    • Die Benutzeridentität innerhalb der Forge dient als Maßstab zur Verifizierung von Nutzern
    • Issues werden zur Verfolgung von Code-Problemen genutzt, Releases zum Erstellen von Veröffentlichungen für Downloads durch Nutzer
  • In solchen Workflows gibt es mehr Forge-Funktionen, die auf git aufsetzen, als git selbst, daher gibt es beim Bau einer neuen Forge weniger Grund, zwangsläufig an die Einschränkungen von git gebunden zu bleiben

Gewünschte Funktionen einer neuen Forge

  • Feedback sollte nicht nach dem Commit, sondern davor kommen

    • In typischen PRs folgen oft Commits wie Feature, fix, fix, actually fix, please, asdfasdf
    • Wenn die Feedback-Schleife erst nach dem Commit greift, müssen Nutzer bis spät in die Nacht Korrekturen machen und leiden unnötig
    • Die Forge sollte erzwingbare Pre-Commit-Hooks bereitstellen, die Arbeiten remote ausführen, damit Nutzer Feedback erhalten, bevor sie pushen

  • PR-Freigaben sind zu binär

    • Aktuell sind PRs entweder freigegeben oder nicht, aber in echten Code-Reviews gibt es viel Raum dazwischen
    • Auch menschliche Reaktionen wie „erst mal okay, kümmern wir uns später darum“ sollten sich über Buttons ausdrücken lassen
    • Gerrit bietet dafür ein besseres Modell
    • Wenn ein Maintainer eine schwache Zustimmung gibt, sollte dies markiert werden können, damit man später noch einmal darauf zurückkommt

  • PR-Richtlinien sollten flexibler sein

    • Nicht jede Änderung braucht eine Vier-Augen-Prüfung, besonders nicht in einer Welt, in der es LLMs gibt
    • Es ist unverhältnismäßig teuer, bei einem PR mit vier Zeilen nur darauf zu warten, dass ein Senior Engineer LGTM hinterlässt
    • Wenn der Autor ein Maintainer ist und ein LLM die Änderung als risikoarm oder risikolos einstuft, sollte sich das leichter so steuern lassen, dass sie direkt weitergehen kann

  • Stacked PRs sollten eine erstklassige Funktion sein

    • Stacked PRs machen Reviews und das Verständnis einfacher
    • Sie sollten nicht nur Zusatzfunktionen über externe Werkzeuge sein, sondern in Forge und VCS als erstklassige Bürger behandelt werden

  • Eine Forge sollte nicht versuchen, alles zu machen

    • Issue-Tracking ist nötig, aber ein Kanban-Board wahrscheinlich nicht
    • Auch der Nutzen eines Wikis ist fraglich
    • Werkzeuge, die jede Funktion einbauen, verlieren am Ende an Qualität, und neue Features sind zwar leicht hinzugefügt, verursachen aber unabhängig von der Akzeptanz dauerhaft Wartungskosten
    • Sobald jemand irgendwo anfängt, ein Feature zu nutzen, ist man daran gebunden

  • Die Hosting-Einheit ist zu groß

    • GitHub Enterprise zu betreiben ist eine große Aufgabe, und auch der Betrieb von GitLab ist vergleichsweise aufwendig
    • Diese Produkte sind komplexe Systeme mit vielen beweglichen Teilen
    • Es sollte kleinere, separat hostbare Einheiten geben, die sich zu einer Organisation verbinden lassen
    • Es muss keine globale Federation sein, und es wäre auch okay, wenn man für jede Organisation ein Konto anlegen muss, aber eine Organisation sollte flexibel genug sein, sagen zu können: „Diese 12 Raspberry Pis sind meine Organisation“

  • Das lokale Repository sollte nicht nur Code, sondern das ganze Repository abbilden

    • Eine lokale Kopie sollte nicht nur den Code, sondern das gesamte Repository einschließlich PR-Freigaben und Issues darstellen
    • Man sollte im selben VCS, in dem man Code eincheckt, auch PRs freigeben können
    • Issues sollten sich so durchsehen lassen wie lokale Dateien

  • Man muss nicht immer die Kosten für die Speicherung der kompletten Historie tragen

    • Um mit einem Team sinnvoll zu arbeiten, muss man online sein, also muss man Nutzern nicht immer die gesamte Speicherlast aufbürden
    • VCS und Forge sollten zusammenarbeiten
    • Beim Klonen eines Repositories könnte man nur eine begrenzte Historie erhalten, und wenn man weiter in die Vergangenheit zurückgehen will, startet man einen Worker, der die nötigen Inhalte aus dem VCS holt
    • Es ist nicht nötig, die Forge ständig mit riesigen Clone-Anfragen zu belasten, nur weil theoretisch irgendwann jemand die Forge aus der vollständigen Projekthistorie neu aufbauen könnte

  • Actions sollten signiert sein, SHA haben und offline nutzbar sein

    • Actions sind wichtig, deshalb braucht es Signaturen, SHA und die Möglichkeit zur Offline-Nutzung
    • Wenn man möchte, sollte man die Tarballs aller Actions herunterladen und im Repository speichern können, und dem System sagen können, es solle die Checkout-Action nicht extern holen, sondern die im lokalen Repository verwenden
    • Wenn man latest angibt, sollte das so funktionieren, dass wie bei Dependabot ein PR geöffnet wird, der den neuesten Tarball ins Repository legt
    • Actions sollten sich auf Wunsch auch über dasselbe VCS auf dem lokalen Rechner ausführen lassen

Es gibt schon Werkzeuge, die Teile davon können, aber es braucht die Kombination

  • Es gibt bereits viele Werkzeuge, die einige dieser Anforderungen erfüllen
  • Nötig ist, diese Werkzeuge zu nehmen, zusammenzufügen und sauber aufeinander abzustimmen
  • Die gewünschte Kombination ist JJ als VCS, ein neues System als Forge und die Erwartung, dass Nutzer lange zufrieden nur mit einem einzelnen Raspberry Pi als Forge arbeiten können
  • Die neue Forge sollte um moderne Konzepte wie Objektspeicher, Shallow Clone und fortlaufende Anfragen von LLM-Bots herum entworfen werden

Risse im Zeitalter von GitHub als Standard

  • Wenn GitHub seinen Job gut gemacht hätte, gäbe es keinen Anlass, solche Ideen aufzuschreiben
  • GitHub ist der Standard, und Menschen davon zu überzeugen, über den Standard hinauszugehen, ist meist fast Zeitverschwendung
  • Wenn man bis 2026 eine Forge genutzt hat, brauchte man einen sehr starken Grund, nicht das Werkzeug zu wählen, das alle benutzen
  • Bis vor Kurzem wurden andere Forge-Plattformen nicht als echte Wunschoptionen wahrgenommen, sondern eher als Ersatzprodukte
  • Aber die einzelne riesige Forge bricht auseinander, und ein Ersatz ist noch nicht gebaut
  • Die Leute mit Geld sind mit Raketen beschäftigt, die Leute mit Geschmack mit ihrem Hauptjob, und der Rest eröffnet um Mitternacht einen PR namens asdfasdf, wartet auf die Roboterprüfung und fragt sich, seit wann Werkzeuge, die man den ganzen Tag benutzt, nicht mehr für ihre Nutzer gemacht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Die Kritik, PR-Freigaben seien zu binär, wirkt widersprüchlich. Eine PR-Freigabe ist eine Autorisierung und damit letztlich zwangsläufig ein Boolescher Wert: Entweder man kann den Code mergen oder eben nicht.
    Gemeint ist hier eher ein Mechanismus, mit dem man sich etwas besser fühlen kann, wenn man Code freigibt, den man eigentlich nicht mag, etwa mit einem Kommentar wie „muss später noch mal geprüft werden ...“. Man könnte einfach ein neues Ticket aufmachen.

    • Gerrit hat Werte von -2 bis +2.
      -2: Schlechte Idee, nicht machen
      -1: Gute Idee, aber Verbesserungen nötig
      +1: Sieht gut aus, aber mir fehlt das Wissen oder die Berechtigung für eine Freigabe
      +2: Freigabe
    • Ich hätte gern einen Button, mit dem man sagen kann: „Diese 3 Commits jetzt freigeben und mergen, diese 2 müssen überarbeitet werden.“
    • Es gibt auch Fälle, in denen Code freigegeben, aber nicht gemergt wird. Dann fügt ein Maintainer weitere Änderungen hinzu und wendet ihn manuell an; dabei kann der PR-Autor als Co-Autor des Änderungs-Commits eingetragen werden.
    • Das größere Problem scheint mir zu sein, dass GitHub zu stark vom Issue-Tracking-System getrennt ist. Man muss ständig manuell synchronisieren, und Linear nimmt einem zwar einen Teil davon ab, aber ideal ist das nicht.
    • „Entweder man kann den Code mergen oder nicht“ — klingt nicht gerade nach einem Intuitionisten.

  • Es stimmt schon, dass „Y einen Teil davon kann“, aber tangled.org kann tatsächlich das meiste davon.

    1. JJ als Versionsverwaltungssystem verwenden: tangled unterstützt gestapelte PRs über jj change-id. https://blog.tangled.org/stacking Auch tangled selbst wird stark auf diese Weise gebaut: https://tangled.org/tangled.org/core/pulls
    2. Eine Forge, die lange auf einem Raspberry Pi laufen kann: Das geht ebenfalls. Der git-Server-Shim ist sehr leichtgewichtig; es ist nur eine XRPC-Schicht über git-Repositories plus eine sqlite3-Datenbank. Jemand betreibt das sogar auf einem RISC-V-Board mit 512 MB RAM.
    3. Actions sind wichtig und sollten lokal ausführbar sein: Ich finde, das geht etwas am Punkt vorbei. Abgeschlossene, überall ausführbare Builds inklusive Cross-Builds sind im Allgemeinen Aufgabe des Build-Systems. Es wäre aber wirklich großartig, wenn man solche Build-Ergebnisse in die Forge selbst „promoten“ könnte.
    • Es überrascht mich, dass beim Hosting von für den Workflow kritischen Daten ein Raspberry Pi ins Spiel kommt. Ich habe früher zu oft beschädigte SD-Karten erlebt und frage mich, ob man heute dafür NVME-Laufwerke nutzt.
    • Stimmt, das ist Aufgabe des Build-Systems. Das Problem, das Leute mit lokal ausführbaren Actions lösen wollen, ist aber meist nicht der Build-Fehler selbst, sondern die Gesamtintegration.
      Also Dinge wie YAML-Definitionen, Secrets, welche Befehle exakt ausgeführt werden und wie Tools und Caches wiederhergestellt werden. Ein Build-System kann einen Teil davon übernehmen, aber die primitiven Funktionen, die GHA dafür bietet, sind sehr schwach. Am Ende läuft es darauf hinaus, das ganze System woanders ausführen zu müssen, weshalb solche Systeme oft per Trial-and-Error entstehen.
    • Genau, und noch darüber hinaus wäre es gut, das Konzept des hermetischen Builds so zu erweitern, dass man ihn lokal oder überall dort mit Rechenressourcen einfach ausführen kann.
      Das grundlegende Problem hier ist, dass es sehr schmerzhaft ist, in einem Kreislauf aus Änderungen, Commits und Netzwerkaufrufen so lange zu iterieren, bis die CI grün wird. Der beste Weg, diese Schleife zu vermeiden, ist natürlich, niemals Bugs zu schreiben! Nur ein Scherz.
    • Radicle und Tangled verfehlen beide den Kern. Sie sind für öffentliche kollaborative Arbeit gedacht, aber was ist mit privaten Repositories? Viele Nutzer haben Side Projects und verwenden dafür GitHub Private.
      Wer GitHub einmal gelernt hat, startet auch öffentliche Projekte dort. Solange man keine privaten Repositories für Side Projects anlegen kann, wird es schwer, breite Nutzung zu erreichen. Die Leute wollen private Repositories anlegen, ein paar Monate verschwinden und dann zurückkommen, wobei alles noch genauso auf sie wartet.
    • Wow, der jujutsu-Support von Tangled ist genau das, wonach ich gesucht habe. Mein Wochenende wird wohl für ein Self-Hosting-Setup draufgehen.

  • Wenn man nur einen begrenzten Verlauf klonen und ältere Daten bei Bedarf nachladen will, kann man blobless clone verwenden.
    git clone --filter=blob:none
    Damit holt man den Verlauf, aber die Blobs nur bei Bedarf. GitHub hat dazu einen guten Artikel: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • Wenn die Lösung selbst zum Problem wird, entsteht Raum für disruptive Innovation. Darüber wird im Moment viel gesprochen, und ich frage mich, ob eine der vielen neuen Alternativen genug Schwung bekommt, bevor GitHub den Kurs korrigiert.

    • Ich denke, das Problem ist, dass Microsoft voll auf AI setzt. Es gibt kein Zurück mehr, und GitHub wird davon zwangsläufig betroffen sein.
      Microsofts PR wird behaupten, AI sei die Lösung für alles, aber in der Realität werden dieselben Probleme immer wieder auftreten. GitHub-Ausfälle müssen nicht direkt mit AI zusammenhängen, aber Microsofts Strategie hat sich bereits geändert, sodass die meisten Entscheidungen einer AI-zentrierten Top-down-Steuerung untergeordnet werden. Ob dadurch die Workflows von GitHub-Nutzern kaputtgehen, ist für Microsoft bestenfalls Nebensache, und deshalb wird das Problem immer wieder auftauchen. Vielleicht ist drei Monate lang Ruhe, aber ich bin mir zu 100 % sicher, dass bald wieder das nächste Drama darüber kommt, wie GitHub verfällt. Ghostty wird nicht das letzte Beispiel gewesen sein. Ob Alternativen entstehen, ist spannend — aber sie dürfen nicht schlecht sein, und viele Websites sind ziemlich mies.
    • Ich baue meine Tools selbst, und ich finde, andere Leute sollten ihre eigenen Tools ebenfalls selbst bauen.
      Vielleicht bekommt man in Zukunft statt proprietärer oder Open-Source-Software einfach ein Bündel Anforderungsdokumente für eine Code-Forge, also eine Art Rezept. Jeder backt sie sich dann selbst und passt sie an den eigenen Zweck und Geschmack an.

  • Ich glaube, es gibt eine Marktlücke für einen viel einfacheren git-Dienst. Alles, was ich brauche, ist ein Remote-Host, auf den ich mein Projekt pushen kann, damit andere es sehen. Dinge wie PRs oder Actions will ich gar nicht unbedingt.
    Eine „Release“-Funktion zum Hochladen lokal gebauter Binär-Assets wäre allerdings nett. Forks kann man dadurch abbilden, dass Leute das Repository klonen und als neues Projekt hochladen.

    • Lässt sich vieles davon nicht lösen, indem man ungewollte Funktionen einfach abschaltet? Ich habe gerade in meine Forgejo-Instanz geschaut, und dort gibt es pro Repository Optionen zum Deaktivieren von Code, Projects, Releases, Packages, Actions, Issues, PRs und Wikis.
    • https://sr.ht/
    • Heißt das, wir kehren wieder zu cgit zurück?

  • Die Behauptung, dass man Review-Daten genauso wie Quellcode in ein git-Repository legen kann, ist ziemlich überzeugend.
    Mit einem bekannten Präfix und einem Branch pro Review wäre das sehr leicht umzusetzen, aber der Standard-Namespace für Branches würde schnell unübersichtlich. Man könnte ihn per git namespaces vom Haupt-Namespace trennen oder einen speziellen Branch wie .reviews verwenden, der nur die Commit-IDs am Ende jedes Review-Branches enthält. Wenn sich jemand genug dafür interessiert und eine Spezifikation plus eine in der Praxis nutzbare Implementierung baut, könnten Leute anfangen, das zu übernehmen. Dass GitHub und verschiedene andere Forges diesen Weg nicht gegangen sind, liegt vermutlich daran, dass Review-Metadaten innerhalb ihres Ökosystems zu halten Teil ihres Plattformwerts ist. Wenn jeder mit lokalen Tools nach Wahl den Code anderer Leute reviewen könnte, würde das den Vendor-Lock-in verringern. Es gäbe allerdings auch andere Gründe, Review-Metadaten in ein anderes Repository legen zu wollen, etwa Zugriffskontrolle oder repository-übergreifende Reviews.

  • Ich mag den Gerrit-Workflow, bei dem nicht die PR, sondern der Diff reviewt wird, wirklich sehr. Aber im Vergleich zu etwas wie gitea fehlen ihm die übrigen Funktionen, die man inzwischen von git-Hosting erwartet, etwa Issues oder Projektplanung, weshalb es sich für viele wohl schwer verkaufen lässt.
    Eine gute Diff-Review-Plattform wie Phabricator wäre schön, aber da gibt es eine Lücke.

    • Aber warum baut Gitea so etwas nicht ein? Den Rest haben sie doch schon — ich verstehe nicht, warum diese Forges immer nur GitHub-Klone bleiben und nicht darüber hinausgehen.

  • Ich finde, man sollte RFC2822 als Basisformat für die Speicherung aller Nachrichten wie PRs, Review-Kommentare und Issues verwenden und für die Darstellung dann CommonMark darüberlegen.
    Alle Metadaten kommen in Header, und über Message-ID-, In-Reply-To- und References-Header kann man sie miteinander verknüpfen. Mit so einem gut definierten Format kann man frei wählen, wie man alle Nachrichten speichert und transportiert: im git-Repository, per E-Mail oder auf andere passende Weise. Bei Code-Review finde ich persönlich Gerrit viel besser als GitHub und Ähnliches. CI würde ich so weit wie möglich auslagern und nur Hooks behalten, die Pipelines starten, Ergebnisse anzeigen und entscheiden, ob gemergt werden darf.

    • Einer der Reize von GitHub ist meiner Meinung nach, dass es Code-Review, Source-Browsing, Ticket-Tracking und CI zusammenführt.
      Keines der vier Dinge macht es überragend gut, aber das Zusammenbinden funktioniert gut. Ich stimme zu, dass Gerrit das bessere Code-Review-Modell hat, aber ohne die anderen drei Teile hat man kein Produkt. Selbst als ich bei Google täglich mit Gerrit gearbeitet habe, war ich unzufrieden mit der schwachen Integration zwischen Codesuche, Code-Review und CI. Interne Google-Tools wie Google3/Critique/Forge haben all das deutlich besser miteinander verzahnt.

  • Mir fällt ein Vorteil von E-Mail-basierten Workflows ein. Wenn man anfängt, E-Mails anzuschauen, ist man oft in der richtigen mentalen Verfassung, und in diesem Zustand erwartet man keine anderen Ablenkungen, weshalb man sich besser konzentriert.
    Das Problem mit Benachrichtigungen ist, dass sie den Drang erzeugen, sie sofort wegzuräumen. Aber das heißt noch lange nicht, dass man in diesem Moment auch die Energie hat, sich darum zu kümmern. Die meisten Benachrichtigungssysteme im Web wirken wie schlechte Nachahmungen dessen, was E-Mail-Clients schon vor Jahrzehnten geschafft haben. Vielleicht hatten die Alten mit E-Mail tatsächlich recht.

    • E-Mail ist doch auch eine Benachrichtigung — könntest du genauer erklären, wie man genau in dem Moment in der Stimmung ist, sie zu empfangen?

  • Als Microsoft GitHub geschluckt hat, waren schon damals viele Leute genervt. Praktisch gesehen waren die Alternativen aber oft einfach schlecht. Bei Sourceforge war das Anlegen von Issues endlos frustrierend, GitLab ist besser als Sourceforge, aber auch dort mache ich ungern Issues auf. Codeberg hat seine UI offenbar kürzlich geändert, fühlt sich aber immer noch ziemlich unbequem an.
    Was GitHub anfangs gut gemacht hat, war die UI und der Fokus darauf, Dinge für Menschen, die GitHub benutzen, einfach oder einfacher zu machen. Nicht alles war gut — die Wiki-Unterstützung finde ich grauenhaft. So schlecht, dass ich Wikis fast nie benutze. Das wirklich große Problem sind meiner Meinung nach kommerzielle Interessen, also private Interessen. Microsoft ist nur ein Beispiel; ähnliche Probleme gibt es fast überall auf solchen Seiten. Ich hatte früher eine Issue-Diskussion zum xz-Backdoor-Hilfsprogramm als Beispiel erwähnt und selbst daran teilgenommen, und am nächsten Tag hat Microsoft alles gelöscht. Ob es Microsoft oder der Repository-Besitzer war, ist dabei nicht wichtig. Das Problem ist, dass Einzelne potenziell nützliche Informationen viel zu leicht zensieren können. Diese Issue-Diskussion war nützlich und wurde zensiert. Soweit ich mich erinnere, wurde damals nicht alles wiederhergestellt. Vielleicht hat es jemand gespiegelt, aber ich habe keinen Link gesehen. Das zeigt, wie schädlich Top-down-Kontrolle sein kann. Ehrlich gesagt: Wie weit kann man Microsoft überhaupt trauen? Wir brauchen etwas Dezentralisiertes, das stabil und zuverlässig funktioniert, mit guter Standard-UI und einfachen oder zumindest guten Workflows. Man muss auch vermeiden, dass private Akteure alle anderen als Geiseln halten. Ich weiß überhaupt nicht, wie man das lösen soll; vielleicht braucht es mehrere Ansätze gleichzeitig. Das Web hat sich verändert, und besonders die privaten Interessen riesiger Megakonzerne haben die Lage in den letzten 10 bis 15 Jahren deutlich verschlechtert. Das muss sich ändern.

    • Das Problem ist, dass der Betrieb eines SaaS-Produkts viel Geld kostet.
      Große Unternehmen können diese Kosten tragen, aber viele Entwickler mit kleinem Budget zusammen haben trotzdem nicht genug Geld dafür. Deshalb unterstützt am Ende fast jedes kommerzielle Projekt eher die Interessen großer Unternehmen als die der durchschnittlichen Person.