GitHub und das Verbrechen an der Software

• GitHub wird zwar wie das Rückgrat der Entwicklungsinfrastruktur genutzt, doch häufige Incidents, langsame Seiten und Browser-Probleme erschüttern nach Einschätzung von Kritikern die grundlegende Zuverlässigkeit
• Microsoft erklärte, die Last sei durch agentic workflows stark angestiegen, zugleich wächst aber die Kritik, GitHub habe die Nutzung durch das aktive Hineindrängen von Copilot- und Agent-Funktionen selbst befördert
• In einem Minimal-Repository-Experiment lud GitHub 291 Requests, 15 MiB komprimierte Antworten und 544.564 expandierte Zeilen herunter und stand damit in starkem Kontrast zu den 11 Requests von Codeberg
• Bei Frontend-Messungen lag der normale Heap von GitHub bei etwa 69 MiB, die Pull-Request-Seite von rust-lang nutzte 148 MiB und galt damit für eine textzentrierte Seite als übermäßig verschwenderisch
• Das Fazit lautet, dass die Verschwendung bei GitHub nicht nur eine Produktverschlechterung ist, sondern ein Softwareversagen zugunsten von AI-Funktionen und investorengetriebenen Prioritäten statt echter Nutzerproblemlösung

---

Zuverlässigkeit und Prioritäten von GitHub

• GitHub wird zwar wie das Rückgrat der Softwareentwicklungsinfrastruktur genutzt, steht wegen Ausfällen, Leistungseinbrüchen und Browser-Kompatibilitätsproblemen aber beim Thema grundlegende Zuverlässigkeit in der Kritik
• Im GitHub-Statusverlauf finden sich jeden Monat Dutzende Incidents, und auch gemessen an der offiziellen Statusseite und dem SLA gab es Situationen, die als Verstöße gewertet werden könnten
• Kritisiert wird, dass GitHub in Firefox und Safari häufig kaputtgeht, Pull-Request-Kommentare und Review-Seiten langsam sind und RAM-Verbrauch sowie Heap-Spitzen übermäßig hoch ausfallen
• GitHub Actions gelten als langsam und schlecht dokumentiert, und die Log-Ansicht wird als Ursache für Memory Leaks und Browser-Abstürze über mehrere Jahre hinweg angeführt
• Selbst das Cache-Verhalten grundlegender Actions wie setup-go wird als unzureichend invalidiert oder übermäßig simpel bewertet
• Es gibt Seiten wie githubstars.com, die offen mit dem Kauf von Stars werben, zudem wird aus einer Carnegie-Mellon-Arbeit der Satz „fake stars are highly related to malicious activities“ zitiert
• Eigentlich müsste GitHub auf hochperformante, hochverfügbare, verteilte Systeme mit hoher Kapazität ausgerichtet sein, tatsächlich werde im Produkt aber AI-Funktionen und Agent-Workflows Vorrang vor grundlegender Zuverlässigkeit gegeben

„Agentic“-Last und Microsofts Verantwortung

• In „an update on github availability“ erklärte GitHub, seit der zweiten Hälfte des Dezember 2025 hätten sich agentic development workflows stark beschleunigt, und Repository-Erstellung, Pull-Request-Aktivität, API-Nutzung, Automatisierung und Workloads großer Repositories seien schnell gewachsen
• Diese Erklärung behandle die steigende Last wie ein externes Phänomen, führe aber zur Kritik, dass GitHub und die Muttergesellschaft Microsoft die Nutzung durch das aggressive Einbauen von AI und „agents“ in zahlreiche Produkte selbst vorangetrieben hätten
  • In der oberen Leiste fast jeder GitHub-Seite befinden sich drei AI-Buttons, davon zwei speziell zum Starten von Agents, auf vielen Seiten sogar vier
  • Im rechten oberen Bereich einer normalen Repository-Landingpage gibt es vier Möglichkeiten, Copilot zu starten
  • GitHub habe über Jahre die Nutzungskosten solcher Tools subventioniert, um ihre Einführung voranzutreiben; ein Kritikbeitrag setzt das damit gleich, sich selbst einen verteilten Denial-of-Service finanziert zu haben
• Microsoft erklärt, dass schon ein einzelner Pull Request Git-Repository, Mergeability-Prüfung, Branch Protection, GitHub Actions, Suche, Benachrichtigungen, Berechtigungen, Webhooks, APIs, Hintergrundjobs, Cache und Datenbanken berühren kann
• In großem Maßstab können selbst kleine Ineffizienzen zu tieferen Queues, Cache Misses, Datenbanklast, Indexverzögerungen und verstärktem Retry-Traffic führen, bei GitHub seien diese Ineffizienzen jedoch nicht „klein“, sondern gewaltig und erdrückend
• Microsoft erklärte zwar „availability first, then capacity, then new features“, doch im öffentlichen GitHub-Changelog tauchte in den 30 Tagen nach diesem Update in den Patch Notes „copilot“ 59-mal, „agent“ 8-mal und „performance“ sowie „reliability“ kein einziges Mal auf
  • In den Changelog-Filtern gibt es eine eigene Kategorie copilot, aber keine Kategorien performance oder reliability
  • Auch Visual Studio Code ist direkt mit GitHub und „agentic“-Funktionen integriert; kritisiert wird, dass Agent-Funktionen hinzukommen, während sich Grundfunktionen wie das eingebaute Terminal verschlechtern
• Dass Microsoft Maßnahmen wie die Reduzierung von „unnecessary work“, besseres Caching, Isolierung kritischer Services, das Entfernen einzelner Ausfallpunkte, die Verlagerung performancekritischer Pfade, die Verringerung versteckter Kopplungen, die Begrenzung des Blast Radius und graceful degradation ankündigt, wird als Eingeständnis eines fehlerhaften Systemdesigns interpretiert

Warum das Frontend auf Backend-Probleme hindeutet

• Die Wurzel der Zuverlässigkeitsprobleme von GitHub liegt zwar im Backend und in den Datenbanken, ist von außen aber nicht sichtbar; beobachtbar ist stattdessen der bei jedem Aufruf geladene Frontend-Code wie HTML, JavaScript und CSS
• So wie sichtbare Ratten im Gastraum einer Pizzeria Zweifel an der Sauberkeit der Küche wecken, gilt der offensichtliche Verfall des GitHub-Frontends als Hinweis auf Backend-Probleme, auch wenn er sie nicht beweisen kann
• Die Landingpages von Repositories bei GitHub, GitLab und Codeberg bestehen aus Linklisten, kleinen UX-Elementen, Buttons, Tabs und Suchfeldern, enthalten aber kaum teure Elemente wie interaktive Medien oder Bilder
• Solche Seiten sollten selbst ohne gute Internetverbindung auf fast jedem Computer oder Smartphone günstig laufen; angeführt wird, dass GitHub früher sogar auf einem iPhone 4 mit 3G-Verbindung tatsächlich so funktionierte
• Bei gleicher Funktionalität gilt der beste Code als derjenige, der am wenigsten Netzwerkbandbreite, CPU-Zeit und RAM verbraucht und die wenigsten Bugs hat
• Die Zahl der Frontend-Bugs lässt sich zwar nicht direkt bestimmen, historische Forschung legt jedoch nahe, dass die Zahl der Bugs meist proportional zur Zeilenzahl des Codes ist
  • Steve McConnel, Code Complete, 2nd Ed (2004) wird mit einem Branchendurchschnitt von 1 bis 25 Fehlern pro 1000 Zeilen ausgelieferter Software zitiert
  • Für die Microsoft Applications Division werden intern 10 bis 20 Defekte pro 1000 Zeilen im Test und 0,5 Defekte pro 1000 Zeilen in ausgelieferten Produkten angegeben

Versuchsaufbau und Erhebungsmethode

• Um Störvariablen zu verringern, wurde die Internetgeschwindigkeit auf eine „fast 3G“-Verbindung begrenzt
  • Die Einstellung soll den Einfluss schwankender Netzwerkbedingungen reduzieren und die GitHub-Erfahrung von Kunden in weniger idealen Situationen wie ländlichen Regionen simulieren
• Für alle drei Dienste wurde dasselbe Minimal-Repository ghsucks verwendet
  • ein einzelner Branch master
  • eine einzelne Datei README.md
  • keine zusätzlichen Elemente wie Issues oder Tags
• Verwendet wurden derselbe Browser und derselbe Computer
  • Firefox
  • Apple Macbook Pro M5 Max
  • 48GiB RAM
• Bei jedem Dienst wurden vier Seitentypen untersucht
  • „landing“-Seite: Code-Layout
  • Seite „pull requests“ bzw. „merge requests“
  • Seite „issues“
  • Seite „settings“
• Mit sauberem Cache-Zustand wurde ein HTTP Archive (HAR) gesammelt, um Netzwerkanfragen zu analysieren; nach Abschluss des Ladevorgangs wurde zudem ein Heap-Snapshot aufgenommen, um Schätzwerte für die RAM-Nutzung im Normalzustand zu erhalten
• Für die HAR-Analyse wurde das selbst geschriebene anhar genutzt, für die Analyse der Kompressionsunterstützung testcompress, zur Gegenprüfung pagespeed.web.dev

Heap-Auslastung und Speicherverschwendung

• Die Heap-Auslastung der Standard-Repository-Seite wurde gemessen mit GitHub 69 MiB, GitLab 68 MiB, Codeberg 14 MiB und eblog.fly.dev 1.3 MiB
• Für das Rendern der ersten Issue-Seite von https://github.com/rust-lang/rust/pulls wurden 148 MiB RAM verwendet
• 148 MiB sind mehr Speicher als das ursprüngliche iPhone hatte und werden für eine textzentrierte Seite mit ein paar Links als extreme Verschwendung bewertet
• Als Vergleich werden folgende Gerätespeicher genannt: Apple iphone 1 128 MiB, iphone 4 512 MiB, Sony playstation 2 32 MiB, Nintendo wii 88 MiB usw.

Vergleich von Anfragevolumen und Antwortumfang

• anhar ist ein Go-Programm, das HAR-JSON parst, das HTML, CSS und JavaScript der Antworten mit deno fmt automatisch formatiert und anschließend Anfrage- und Antwortgrößen, Summen nach MIME-Typ, Ladezeit und Anzahl der Antwortzeilen berechnet
• Die wichtigsten Kennzahlen sind Anfragemenge, tatsächlich empfangene minimierte Antwortgröße, die erweiterte Antwortgröße und Zeilenzahl nach Anwendung von deno fmt, außerdem Content-Load als Ladezeit des Basis-HTMLs und Load als Ladezeit aller Inhalte
• Die Codeberg-Repository-Seite wurde insgesamt mit 11 Anfragen, 9 KiB Anfragen, 1 MiB Antworten, 1 MiB erweiterter Antwort, 3.480 erweiterten Zeilen, Content-Load 2.934s und Load 3.172s gemessen
• Die GitHub-Repository-Seite wurde mit 291 Anfragen, 178 KiB Anfragen, 15 MiB minimierter Antwort, 22 MiB erweiterter Antwort, 544.564 erweiterten Zeilen, Content-Load 843ms und Load 21.330s gemessen
  • application/javascript: 214 Anfragen, 12 MiB Antwort, 19 MiB erweiterte Antwort, 481.849 erweiterte Zeilen
  • text/css: 42 Anfragen, 2 MiB Antwort, 60.016 erweiterte Zeilen
  • GitHub pulls: 266 Anfragen, 14 MiB minimiert, 20 MiB erweitert, 487.922 erweiterte Zeilen, Content-Load 592ms, Load 6.754s
  • GitHub settings: 255 Anfragen, 14 MiB minimiert, 20 MiB erweitert, 486.067 erweiterte Zeilen, Content-Load 778ms, Load 6.963s
• GitLab ist kleiner als GitHub, aber weiterhin schwergewichtig
  • GitLab-Repository: 78 Anfragen, 8 MiB Antwort, 101.682 erweiterte Zeilen, Content-Load 6.880s, Load 12.941s
  • GitLab merge_requests: 65 Anfragen, 7 MiB Antwort, 90.567 erweiterte Zeilen, Content-Load 6.947s, Load 12.096s
  • GitLab edit: 117 Anfragen, 7 MiB Antwort, 71.916 erweiterte Zeilen, Content-Load 6.964s, Load 13.302s
• GitHub lädt selbst für die Anzeige eines leeren Repositorys rund 540K Zeilen Code und Daten, was laut Vergleich mehr ist als DOOM mit 35K Zeilen, Windows Quake mit 120K Zeilen, MS-DOS 4.0 mit 332K Zeilen und die Zig-Toolchain mit 460K Zeilen
• Problematisch wird die Struktur bewertet, bei der einzelne Seiten 40 CSS-Dateien und Hunderte JavaScript-Dateien laden
• Die Chunk-Aufteilung von Webpack kann theoretisch Kernfunktionen und optionale Funktionen trennen und Vorteile für Caching und CDN bringen, wird hier aber so interpretiert, dass für jede Datei ein eigener HTTP-Request nötig ist und sich dadurch das Laden verlangsamt
• 22 Sekunden zu warten, um eine leere Seite zu sehen, sei kaum hinnehmbar; selbst bei Glasfaser mit über 1 GiB/s und einem leistungsstarken Consumer-Prozessor dauere es mehr als eine Sekunde, bis ein Repository einigermaßen nutzbar werde

Vergleich der Kompressionsunterstützung

• Kompression wird als nützliche Methode dargestellt, um die Last auf Client, Server und den Zwischenstationen zu senken
• gzip ist ein bewährter Kompressionsstandard und sollte von allen Websites unterstützt werden; zstd hat gute Performance-Eigenschaften, ist aber moderner und wird eher als „nice to have“ behandelt
• testcompress ist ein Go-Programm, das testet, ob eine URL gzip- und zstd-Kompression unterstützt, und andernfalls den Antwort-Body selbst komprimiert, um das potenzielle Einsparvolumen zu zeigen
• eblog.fly.dev/startingsystems3.html: unterstützte Encodings zstd gzip, Original 575.77 KiB, gzip 67.64 KiB, zstd 60.17 KiB
• github.com/ef0xa/ghsucks: unterstützte Encodings gzip, Original 224.70 KiB, gzip 43.27 KiB, zstd 37.96 KiB
• gitlab.com/efronlicht/ghsucks: unterstützte Encodings gzip, Original 43.08 KiB, gzip 11.48 KiB, zstd 11.34 KiB
• codeberg.org/efronlicht/ghsucks: unterstützte Encodings n/a, Original 43.88 KiB, gzip 13.00 KiB, zstd 12.79 KiB

PageSpeed-Mobile-Ergebnisse

• Bei der mobilen Messung von pagespeed.web.dev erhielt Codeberg mit First Contentful Paint 1.2s, Largest Contentful Paint 1.3s und Interaction to Next Paint 86ms ein PASS
• eblog.fly.dev erhielt mit First Contentful Paint 1.1s, Largest Contentful Paint 1s und Interaction to Next Paint N/A ein PASS
• GitHub erhielt mit First Contentful Paint 1.8s, Largest Contentful Paint 2.1s und Interaction to Next Paint 242ms ein FAIL
• GitLab erhielt mit First Contentful Paint 2.1s, Largest Contentful Paint 2.4s und Interaction to Next Paint 243ms ein FAIL

Bewertung nach Dienst

• GitHub

  • Lädt etwa 300 Dateien sowie rund 550.000 Zeilen Code und Daten; die geschätzte Zahl der Bugs wird mit 550 angegeben
  • Content-Load liegt bei etwa 800 ms, der gesamte Load bei etwa 7 s, der Heap im Steady State wird mit rund 69 MiB zusammengefasst
  • gzip wird unterstützt, zstd jedoch nicht
  • Die Bewertung ist F; der Code wird als extrem schwergewichtig eingestuft
  • Kritisiert wird, dass GitHub auf allen Seiten alle Themes lädt, unabhängig davon, ob sie genutzt werden oder nicht
  • Da pagespeed.web.dev angibt, dass 528 KiB JavaScript und CSS vollständig ungenutzt bleiben, wird vorgeschlagen, zunächst dort anzusetzen
  • Wenn man bei GitHub bleiben müsse, verletze der Dienst nach dieser Einschätzung das GitHub-eigene SLA, weshalb vorgeschlagen wird, ein Support-Ticket einzureichen, um eine Rückerstattung zu erhalten

• GitLab

  • Content-Load liegt bei etwa 7 s, Load bei etwa 13 s; geladen werden über 70 Dateien mit 7 MiB und rund 10.000 Zeilen
  • Der Heap im Steady State liegt bei etwa 68 MiB, gzip wird unterstützt, zstd jedoch nicht
  • Die Bewertung ist D+; GitLab gelte zwar nicht als so verschwenderisch wie GitHub, lade aber zu viele Ressourcen und nutze sie nicht sinnvoll
  • Es werden über 1 MiB JavaScript und CSS geladen, von denen Teile tatsächlich überhaupt nicht verwendet werden; zudem gibt es selbst im genutzten Code 3-MiB-Chunks, deren Parsen allein 255 ms dauert
  • Für die Landingpage seien 55.000 Zeilen CSS nicht nötig; sowohl CSS als auch JavaScript könnten vermutlich auf ein Zehntel des aktuellen Umfangs reduziert werden

• Codeberg/Forgejo

  • Content-Load beträgt 2,9 s, Load 3,1 s; geladen werden 1 MiB in 11 Dateien und rund 1.100 Zeilen
  • Der Heap im Steady State liegt bei etwa 14 MiB; weder gzip noch zstd werden unterstützt
  • Die Bewertung ist C+; die Grundlagen seien vorhanden, doch es fehle an Sorgfalt im Detail und an Erfahrung
  • Dass HTML nicht minifiziert wird, gilt als kleines Problem, fehlende Kompressionsunterstützung jedoch als gravierende Lücke
  • Problematisch sei zudem, dass der Großteil von JavaScript und CSS für das Rendern der Seite nicht benötigt werde, aber render-blockierend geladen werde
  • Vorgeschlagen wird, die JavaScript- und CSS-Payloads zusammenzufassen, um die Zahl der Requests zu verringern, und gzip- sowie zstd-Kompression für HTTP-Payloads einschließlich HTML zu unterstützen
  • Als Vorteil wird genannt, dass es sich um freie Software handelt und daher ein Umzug auf andere Instanzen oder Self-Hosting möglich ist

• eblog.fly.dev

  • eblog.fly.dev/startingsystems3.html wurde mit 76 ms Content-Load, 1,1 s Load, 766 KiB in 5 Dateien und rund 3.800 Zeilen gemessen
  • Die einzelne HTML-Datei ist 576 KiB groß und lässt sich mit zstd auf etwa 70 KiB komprimieren
  • Der Heap im Steady State liegt bei etwa 11 MiB; sowohl zstd als auch gzip werden unterstützt
  • Die Bewertung ist A-; insgesamt gut, aber das HTML sei selbst unter Berücksichtigung der Kompression aufgebläht und repetitiv, und eine Seite, die mit einer einzigen Anfrage auskommen könnte, benötige stattdessen 5 Requests

Nicht nur schlichte Produktverschlechterung, sondern ein Kostenproblem

• „enshittification“ wird zusammengefasst als ein Prozess, bei dem ein gutes Produkt zunächst für Nutzer und Geschäftskunden vorteilhaft ist, dann zu Ungunsten der Nutzer verändert wird, danach auch zu Ungunsten der Geschäftskunden und schließlich zugunsten des Betreibers endet
• Microsoft und GitHub stehen zwar nicht völlig losgelöst von Embrace, Extend, Extinguish, doch das Problem hier unterscheide sich dadurch, dass es nicht nur für Nutzer und Geschäftskunden, sondern auch für Microsoft selbst Kosten verursache
• Eine aufgeblähte Codebasis erhöht direkt die Kosten für Server und Bandbreite und verbraucht indirekt Engineering-Zeit für die Wartung einer instabilen und überdimensionierten Codebasis
• Nimmt man an, dass GitHub etwa 800 Ingenieure beschäftigt und jede Person 40 Stunden pro Woche bei 48 Arbeitswochen pro Jahr arbeitet, entspricht das 1.536.000 Ingenieursstunden pro Jahr
• Die meisten Frontend-Probleme ließen sich nach dieser Einschätzung schon dadurch beheben oder abmildern, dass man lediglich den pagespeed-Empfehlungen folgt; ein fähiger Ingenieur könne das innerhalb einer Woche erledigen
• Dass Low-Level-Verbesserungen trotz möglicher Kostensenkungen liegen bleiben, wird als Folge von Gleichgültigkeit, extremer Inkompetenz oder einer Blockade durch eine auf KI und Investoren ausgerichtete Führung interpretiert
• Software wird als ein mächtiges und schönes Werkzeug beschrieben, weil sie sich, einmal richtig geschrieben, perfekt, für immer und kostenlos vervielfältigen lässt, sodass alle sie nutzen können
• Die Verschwendung und Inkompetenz bei GitHub und ähnlichen Diensten führten daher zu dem Schluss, dass es sich nicht nur um schlechte Produkte, sondern um ein Verbrechen an der Software handle

[GN⁺]

Lobste.rs-Kommentare

• Es wäre gut, Trac und Sourcehut ebenfalls in diesen Vergleich einzubeziehen

• Die vier AI-Agent-Buttons sind lustig, und die im Artikel genannten relativen Zahlen sind auch interessant, aber obwohl ich GitHub keineswegs verteidigen will, fehlt einigen Details im Text der Kontext, sodass sie mir nicht ausreichen, um die Argumentation des Autors zu stützen.
  Die Speichernutzung im Leerlauf könnte ein Hinweis darauf sein, dass GitHub mehr macht als Codeberg, aber aus dem absoluten RAM-Verbrauch auf einem 48-GB-RAM-Rechner im Vergleich zum Apollo Guidance Computer sinnvolle Schlüsse zu ziehen, ist schwierig.
  Ein minifiziertes JavaScript-Bundle zu formatieren, um die Zahl der Codezeilen zu schätzen, und das dann mit den Zeilen eines Zig-Projekts ohne Abhängigkeiten zu vergleichen, ist ebenfalls ein Vergleich von Äpfeln mit Birnen. Man könnte genauso gut sagen, man solle doch mal schauen, wie viele Zeilen herauskommen, wenn man die Zig-Binärdatei dekompiliert.
  Ich verstehe auch die Empfehlung an Codeberg nicht, man müsse „JavaScript- und CSS-Payloads zusammenfassen, um die Zahl der Requests zu senken“. Wenn von „zusätzlichem Overhead“ durch HTTP-Requests die Rede ist, frage ich mich, ob der Autor HTTP/2 überhaupt kennt.
  Über die Performance von Webseiten ließe sich noch viel mehr sagen, aber das hebe ich mir für einen separaten Beitrag auf; für eine bessere Perspektive auf ein ähnliches Thema empfehle ich, Danluus Text über Web-Bloat von 2017 noch einmal zu lesen: https://danluu.com/web-bloat

• Falls der Autor mitliest, sollte er sich vielleicht die Debatte zwischen Casey Muratori und Uncle Bob anschauen. Ersterer hat einen sehr interessanten Performance-Einbruch gefunden.
  „Ich konnte nicht widerstehen, habe mir eine Chrome-Performance-Aufzeichnung angesehen und herausgefunden, wer der Schuldige war :) Es war der ‘emoji picker’!“
  „Ich habe den Code nur grob überflogen, aber es sieht so aus, als bestünde das Problem darin, dass der ‘emoji picker’ bei jeder eingegebenen Zeichenfolge rückwärts durchgeht, um zu prüfen, ob das eben Getippte ein Emoji ist.“
  Uff. Wobei in diesem Fall der Schuldige vielleicht nicht der GitHub-Frontend-Code ist, sondern ein Chromium-basierter Browser

• Die Formulierung, „Codeberg sei ein Produkt, das auf unabhängige Spenden und freie Freiwillige angewiesen ist“, ist nicht korrekt.
  Codeberg ist auf Mitglieder angewiesen. Nicht nur finanziell über Mitgliedsbeiträge, sondern auch in seiner Governance; derzeit reichen die Beiträge nicht aus, um festangestellte Mitarbeitende zu beschäftigen, daher stützt man sich stark auf Freiwillige, aber soweit ich weiß, gibt es auch Auftragnehmer.
  Ich verfolge Codeberg nicht besonders eng (ich bevorzuge eher sourcehut), aber dass es sich um eine Genossenschaft handelt, ist meines Erachtens einer der zentralen Teile seines Wertversprechens. Man bemüht sich auch um transparente Offenlegung der Ausgaben. Zum Beispiel: https://blog.codeberg.org/codebergs-budget-of-2026.html
  Wenn ihr Codeberg nutzt, wäre es vielleicht eine Überlegung wert, jetzt Mitglied zu werden: https://join.codeberg.org/

• Ich hasse GitHub wirklich. Mein Problem ist nicht die Uptime, sondern dass es absurd langsam und speicherhungrig ist. „Diffs dieser Größe werden standardmäßig nicht angezeigt“ – ist das euer Ernst?
  Auch für vernünftige Entwicklungsabläufe ist es kaputt. Wenn man einen PR rebased, verschwinden Review-Feedback und Kommentare, und wenn man Commits squasht, verschwinden Review-Feedback und Kommentare ebenfalls.
  Selbst wenn es einen Link zu einem bestimmten Kommentar gibt, verschwindet der Kommentar mit, sobald der betreffende Commit verschwindet \o/
  Wenn es einen Bugfix gibt, soll man dafür einen PR erstellen, und selbst wenn der Bug durch eine andere Änderung behoben wurde, bleiben PR und Bug auf derselben Ebene, sodass tote PRs für immer in der Review-Queue herumliegen.
  Wenn man wissen will, welcher Commit welchen Bug behoben hat, bekommt man nur die PR-Historie gezeigt. Es heißt also sinngemäß: Schau nicht auf den Bug, sondern auf den PR; und wenn du den Bug verstehen willst, such ihn dir selbst.

  • Das Konzept des „pull request“ stammt wie git selbst aus der Linux-Kernel-Entwicklung. Der Ablauf besteht darin, den Kernel-Maintainer zu bitten, Patches in den Mainline-Branch zu „ziehen“.
    GitHub hat diesen Ablauf mit dem „fork“-Button bequemer gemacht, dazu zentralisierte Benutzernamen eingeführt, um alles sozialer zu machen, und einen Issue-Tracker sowie ein Wiki angeflanscht – und damit die Welt erobert. Geschäftlich war das ohne Zweifel genial.
    Aber der gesamte Ablauf ist immer noch auf Open-Source-Entwicklung zugeschnitten, bei der voneinander getrennte Personen darum bitten, dass ihre Patches „gezogen“ werden.
    Ich verstehe nicht, warum eng zusammenarbeitende Entwicklungsteams, bei denen der tatsächliche Mechanismus darin besteht, „einen Branch zu besprechen und die Zusammenführung zu genehmigen“, überhaupt „pull requests“ verwenden sollten. Woraus wird da etwas gepullt? Es ist doch im selben Repository, und die Änderungen wurden bereits gepusht.
    Selbst wenn man die Terminologiefrage ausklammert, ergibt das Fehlen von gestapelten Änderungen, stabilen Kommentaren und Diffs über Änderungssätze hinweg keinen Sinn.
    Tut mir leid, schon wieder diese langweilige GitHub-Beschwerde. Gibt es eine bessere Alternative? Natürlich kann man niemanden dazu zwingen, sie zu benutzen …

• So etwas wie „Grafiken ohne Achsenbeschriftungen oder einzelne Datenpunkte sind immer verdächtig“ habe ich schon ein paar Mal als Reaktion auf von GitHub veröffentlichte Diagramme gesehen.
  Da die Maximalwerte im Diagramm angegeben sind, kann man visuell schätzen, dass die Mittelwerte auf der y-Achse jeweils etwa 45M, 0.7B und 10M betragen. Vorausgesetzt natürlich, es ist nicht heimlich eine Log-Skala und die Last ist nicht um den Faktor 100000 gestiegen.
  Ich würde schlechte Diagramme hier nicht gleich als „verdächtig“ bezeichnen, sondern einfach als schlecht kommuniziert. Persönlich finde ich rohe ggplot-Ausgaben sowieso immer besser.
  Dem allgemeinen Tenor stimme ich zu, aber bei den Teilen mit den dicken Pferden und vielen Tabellen fiel es mir etwas schwer, dranzubleiben. Wenn ich allerdings alle Mängel von GitHub auflisten müsste, würde ich vermutlich auch irgendwann den Verstand verlieren und davon träumen, auf einem dicken Pferd in den Sonnenuntergang zu reiten.
  Ich habe ähnlich angefangen, eine Liste zu machen, und bei ungefähr zwölf UX-/Performance-Problemen aufgegeben. Ich mag die Gründlichkeit dieses Beitrags und hoffe, das GitHub-Team nimmt ihn sich wirklich vor.
  Wie ich früher schon sagte, sollte Microsoft GitHub einige Performance-Ingenieure zuweisen. Solange Performance-Metriken nicht tatsächlich Teil der zentralen KPIs werden, wird dieser Bloat weitergehen und andere Plattformen attraktiver erscheinen lassen. Falls es einen nächsten GitHub-CEO gibt, hoffe ich, dass er das priorisiert.

  • Du gehst davon aus, dass die y-Achse bei 0 beginnt. Bei solchen Business-Grafiken ist das sehr oft nicht der Fall.
    Oft wird „enormes Wachstum“ behauptet, während die Linie im Diagramm den gesamten Bildbereich diagonal durchquert, die y-Achse aber in Wirklichkeit nur von 100 bis 101 reicht

• Ich stimme der Aussage zu, dass „GitHub-Action-Logs seit Jahren Speicher leaken und meinen Browser zum Absturz bringen, und es bis heute keine Möglichkeit gibt, stdout einfach irgendwohin zu pipen“.
  Leider hat Forgejo das ebenfalls geerbt. Manchmal bekomme ich auf dem Handy eine Benachrichtigung über einen fehlgeschlagenen Build und will nur schnell nachsehen, aber in vielen Fällen kann der mobile Browser die Ausgabe überhaupt nicht laden

• Als ich auf diesen Beitrag geklickt habe, war ich völlig sicher, dass es wieder nur eine weitere Beschwerde über die GitHub-Uptime sein würde, aber stattdessen war ich angenehm überrascht: eine ruhige und vernünftige Bewertung der aktuellen Probleme von GitHub, GitLab und Codeberg, inklusive Lösungsvorschlägen.
  Es wäre schön, wenn auch Tangled in den Vergleich aufgenommen würde.
  Der Autor sollte bitte etwas CSS schreiben, damit die Seite auch auf Mobilgeräten lesbar ist. Ich musste den Lesemodus des Browsers verwenden.
  Der einzige Punkt, dem ich nicht zustimme, ist die Behauptung, keine Seite solle mehr als eine JavaScript-/CSS-Datei laden.
  Wenn diese 550.000 Zeilen JavaScript alle in einer einzigen Datei wären, würde das Parsen und Ausführen viel länger dauern. CSS kann man vielleicht bündeln, aber zum Beispiel ein gemeinsamer Chunk plus ein routenspezifischer Chunk kann sinnvoll sein. Ein solcher oder ähnlicher Ansatz dürfte breit eingesetzt werden

• Diese Seite ist unlesbar.
  Und wenn man GitHub nicht mag, dann nutzt man es eben nicht. Es überrascht mich, dass Leute Zeit haben, derart lange Beschwerdelisten zusammenzustellen. Entweder sie werden dafür bezahlt, oder sie sollten einfach etwas anderes verwenden