DiffsHub

 (diffshub.com)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn man einen großen GitHub-Diff schnell im Browser überfliegen muss, ist DiffsHub ein Tool, das öffentliche Diffs in einer virtualisierten Oberfläche anzeigt
  • Wenn man in einer GitHub-URL github.com durch diffshub.com ersetzt, lassen sich PR-, Vergleichs-, Commit-, Diff- und Patch-Änderungen sofort ansehen
  • Ohne separates Konvertierungsverfahren bleibt die bestehende URL-Struktur erhalten, sodass man github.com/org/repo/pull/number einfach als diffshub.com/org/repo/pull/number aufrufen kann
  • Auch Vergleiche mit mehreren Millionen Zeilen wie Linux v6.0...v7.0 sind möglich, auf mobilen Browsern kann es aber gelegentlich zu Abstürzen kommen
  • Da GitHub bei Diffs mit mehr als 100k Zeilen die erste Byte-Antwort verzögert und Inhalte womöglich nicht stabil bereitstellt, kann es für die Prüfung großer Änderungen eine Alternative sein

Diff-Viewer mit unveränderter GitHub-URL

  • DiffsHub ist ein Tool, mit dem sich öffentliche GitHub-Diffs schnell und in einer gut lesbaren virtualisierten Oberfläche ansehen lassen
  • Unterstützt werden PRs, Vergleiche, Commits, Diff und Patch
  • Nutzer greifen darauf zu, indem sie in der GitHub-URL nur die Domain ändern
    • github.com/org/repo/pull/number
    • diffshub.com/org/repo/pull/number

Diffs mit Millionen von Zeilen und Einschränkungen

  • DiffsHub kann auch Vergleiche im Umfang von mehreren Millionen Zeilen verarbeiten
  • Als Beispiel dient der Vergleich Linux v6.0...v7.0
  • Solche großen Vergleiche können auf mobilen Browsern gelegentlich abstürzen
  • GitHub kann Diffs mit mehr als 100k Zeilen nur instabil und mit verzögerter erster Byte-Antwort ausliefern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Lobste.rs-Meinungen

  • Ich habe versucht zu verstehen, was die Diff-Ansicht mit dem Vibecoding-Tag zu tun hat.
    Danach habe ich den Kontext und das Drama aufgeholt und verstanden, warum es so gekommen ist. Tut mir leid, dass ich Lärm gemacht habe gegenüber @quad, und ich sehe jetzt auch, dass das Tag entfernt wurde.

    • Lobsters ist gerade in eine etwas seltsame Phase geraten, in der Leute nach Belieben entscheiden, ob ein Projekt „vibecoded aussieht“.
      Zum Beispiel wird das Vibecoding-Tag schon wegen niedriger Codequalität, einer geringen Zahl an Commits oder sogar nur deshalb vergeben, weil ein Repository eine CLAUDE.md enthält; das scheint ziemlich bedeutungslos zu sein.
    • Im Repository gab es eine CLAUDE.md. Hier wurde sie fälschlich entfernt, und ich denke, bei diesem Beitrag war das ein passendes Tag.
    • Zum Glück scheint das Tag inzwischen verschwunden zu sein.

  • Als zusätzlicher Kontext scheint dieser Beitrag relevant zu sein: On Rendering Diffs
    Auch beim Durchsehen des auf der Homepage verlinkten Linux-Diffs war ich beeindruckt, wie flüssig es lief. Das merkt man, wenn man die Scrollbar direkt zieht. Ich wünschte, GitHub oder andere browserbasierte Diff-Editoren sowie das bei der Arbeit verwendete Graphite wären ähnlich flüssig.
    Andererseits ist es schon seltsam, dass mich so etwas überhaupt beeindruckt. Eigentlich sollte das doch Standard sein, oder nicht?

    • Ich kenne sowohl die Person, die den Großteil der Diff-Rendering-Arbeit gemacht hat, als auch den Autor des Beitrags. Währenddessen bekam ich per Textnachrichten Live-Updates, und es war wirklich beeindruckend, wie viel Recherche und Arbeit hineingeflossen ist.
      Wörtlich genommen bestand monatelange Vollzeitarbeit darin, Diffs schnell zu rendern.
      Übrigens wurde dafür zwar das „Vibecoding“-Tag vergeben, aber ich verstehe das immer noch nicht, und diese Arbeit war überhaupt nicht von dieser Art. Das meiste war schwierige Recherche, das Lesen von Browser-Implementierungscode, Trial-and-Error und das methodische Durchdringen des Problems.
      Für sehr eng begrenzte Erkundungsaufgaben mit klarer Belohnung wurden Agent-Loops eingesetzt, aber soweit ich weiß, gab es nichts ohne menschliche Einsicht und Prüfung. Der Blogbeitrag scheint das ebenfalls zu behandeln, und es machte nur einen sehr kleinen Teil der gesamten Arbeit aus. Allein deshalb die Ingenieursleistung herabzusetzen, ergibt keinen Sinn.
      Ich empfehle nachdrücklich, den Blogbeitrag zu lesen oder sich den Code anzusehen. Es ist erstaunliche Arbeit, und man kann viel daraus lernen.
    • Das sollte wirklich Standard sein. Ich hoffe, dass GitLab und Forgejo das ebenfalls übernehmen.
      Ich habe zum direkten Testen ein Bookmarklet gebaut: 
      javascript:(function(){window.open(window.location.href.replace('github.com','diffshub.com'),'_blank');})();
      Leider braucht man bei vielen PRs, besonders großen, eine Kommentarfunktion. Man wird sehen müssen, wann Pierre diesen Bereich ebenfalls angeht und zum Beispiel etwas wie https://www.reviewable.io/ baut.

  • npmjs sagt Apache 2, aber im Repository gibt es keine Lizenz, und in der package.json steht sogar "private":true, daher war schwer zu erkennen, warum.
    Die Antwort scheint zu sein, dass jede Directory einzeln lizenziert wird: https://github.com/pierrecomputer/pierre/…
    Und diffshub selbst scheint nicht zu den Open-Source-Teilen zu gehören: https://github.com/pierrecomputer/pierre/…
    Diese Art von chirurgischer Lizenzierung lässt Directories wie https://github.com/pierrecomputer/pierre/… in einem unklaren Zustand. Dort gibt es nämlich keine Apache-2-LICENCE.md, auch wenn die Sache anders aussehen könnte, wenn man das package.json-Feld als maßgeblich ansieht.

  • Die UI wirkt bis auf den Kontrast besser als bei GitHub. Bei der Barrierefreiheit bin ich mir nicht sicher.

  • Zur Info: Bei allen Pull Requests auf GitHub kann man hinten .diff anhängen, um den Diff zu bekommen.
    Beispiel: https://github.com/oven-sh/bun/pull/30412.diff
    Wenn man .patch anhängt, bekommt man auch ein Format, das man an git am übergeben kann: https://github.com/oven-sh/bun/pull/30412.patch

    • error: too big or took too long to generate
      Hat man diesen PR vielleicht absichtlich deswegen ausgewählt? :D

  • Vielleicht sind meine Erwartungen an Tools niedriger als die anderer Leute, aber wenn ich das mit der eingebauten GitHub-Funktion vergleiche, sehe ich nicht wirklich einen praktischen Unterschied.
    Alle beklagen, wie schlecht GitHub sei, aber ich habe diese Erfahrung nicht gemacht. Ich verstehe nicht, warum ich das statt GitHub benutzen sollte.

    • Ich habe ein Video aufgenommen, das zeigt, warum das für mich wichtig ist. Entschuldigung, dass es auf X ist, aber ich habe es dort hochgeladen.
      Historisch gesehen war das meine typische allgemeine Erfahrung, und es erklärt auch, warum Geschwindigkeit wichtig ist. Wenn eine Aufgabe lange genug langsam ist, schweifen meine Gedanken ab, und das stört den Flow-Zustand erheblich.
      Das Video vergleicht nebeneinander die Zeit, die es dauert, einen PR zu öffnen und zu einer bestimmten Datei zu springen. Für mich ist das eine ziemlich übliche Alltagsaufgabe.
      https://x.com/mitchellh/status/2057229385963618787

  • Es sieht pulldash (von coder.com) oder difit (eine CLI, die eine localhost-Seite startet) ziemlich ähnlich.
    Ich mag beide nicht besonders. pulldash war etwas ruckelig, und difit erforderte zusätzlichen Aufwand. Für Self-Reviews nutze ich derzeit die VSCode-Erweiterung git tree compare.
    Die ist schnell, und auch das allgemeine visuelle Design gefällt mir. Ich habe es mit einem meiner PRs ausprobiert, und es wirkte ordentlich genug; ich könnte es mir auch auf dem PC als Lesezeichen speichern.