1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 大規模な GitHub diff をブラウザで素早く見渡したいとき、DiffsHub は公開 diff を 仮想化インターフェース で表示するツール
  • GitHub URL の github.comdiffshub.com に置き換えると、PR、比較、コミット、diff、patch の変更内容をすぐに見られる
  • 別途変換手順なしで既存の URL 構造を維持し、github.com/org/repo/pull/numberdiffshub.com/org/repo/pull/number のように変えてアクセスする
  • Linux v6.0...v7.0 のような 数百万行の比較 も扱えるが、モバイルブラウザでは時々クラッシュすることがある
  • GitHub は 100k 行超の diff では最初のバイト応答が遅延し、安定して提供されないことがあるため、大きな変更をレビューする際の代替として見られる

GitHub URL をそのまま使う diff ビューア

  • DiffsHub は公開 GitHub diff を高速で見やすい仮想化インターフェースで確認できるツール
  • 対応対象は PR、比較、コミット、diff、patch
  • ユーザーは GitHub URL でドメインだけを変更してアクセスする
    • github.com/org/repo/pull/number
    • diffshub.com/org/repo/pull/number

数百万行 diff と制約

  • DiffsHub は数百万行規模の比較も扱える
  • 例として Linux v6.0...v7.0 の比較 を見られる
  • こうした大規模比較は モバイルブラウザ で時々クラッシュすることがある
  • GitHub は 100k 行超の diff を、最初のバイトが遅延した状態で不安定に提供することがある

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rs の意見
  • diff 表示と vibecoding タグ がどう関係するのか理解しようとしていた
    その後、文脈と経緯を追って、なぜこうなったのか理解した。騒ぎを起こして @quad に申し訳ないし、今はタグも外されたのを確認した

    • Lobsters は少し妙な局面に入っていて、プロジェクトが「vibecoded に見えるか」を人々が勝手に判断している
      たとえばコード品質が低い、コミット数が少ない、果てはリポジトリに CLAUDE.md があるという理由だけで vibecoding タグを付けていて、あまり意味がないように見える
    • リポジトリに CLAUDE.md があった。ここでは誤って外されたが、この記事には適切なタグだったと思う
    • 幸い、そのタグはもう消えたようだ
  • 追加の文脈としてはこの記事が関係ありそう: On Rendering Diffs
    ホームページにリンクされた Linux diff を見て回るときもかなり滑らかで印象的。スクロールバーを直接ドラッグしてみれば分かる。Github や他のブラウザベースの diff エディタ、職場で使っている Graphite もこのくらい滑らかだったらいいのにと思う
    一方で、こんなことに感心している事実自体がおかしい。本来これが標準であるべきではないかと思う

    • diff レンダリング作業の大半を担当した人と、その記事の著者を知っている。進行中にメッセージでリアルタイム更新を受け取っていたが、どれほど多くの調査と作業を注ぎ込んだのか本当にすごかった
      文字どおり数か月のフルタイム業務が diff を高速にレンダリング できるようにすることだった
      ちなみに “vibecoding” タグが付いていたが、やはり理解できないし、この作業はまったくそういう類いではなかった。大半は困難な調査、ブラウザ実装コードの読解、試行錯誤、問題を正攻法で掘り下げることだった
      非常に狭く、成果が明確な探索作業にはエージェントループが使われたが、私の知る限り人間の洞察やレビューなしで投入されたものはなかった。ブログ記事でもこの点に触れているようで、全体の作業に占める割合は本当に小さかった。その理由だけで 工学的努力 を矮小化するのは筋が通らない
      ブログ記事を読むかコードを見ることを強く勧める。驚くべき仕事で、学ぶことが多い
    • 本当にこの程度が標準であるべきだ。Gitlab と Forgejo にも取り入れてほしい
      自分で試すためにブックマークレットを作った:
      javascript:(function(){window.open(window.location.href.replace('github.com','diffshub.com'),'_blank');})();
      
      残念ながら多くの PR、特に大きな PR ではコメント機能が必要だ。Pierre がいつこの領域まで持っていって、たとえば https://www.reviewable.io/ のようなものを作るのか見守りたい
  • npmjs では Apache 2 とされているのに、リポジトリにはライセンスがなく、package.json には "private":true まであって、理由を見つけにくかった
    答えは、各ディレクトリが個別にライセンスされる構造らしい: https://github.com/pierrecomputer/pierre/…
    そして diffshub 自体はオープンソース部分に含まれないようだ: https://github.com/pierrecomputer/pierre/…
    こうした 外科手術的ライセンス 方式は https://github.com/pierrecomputer/pierre/… のようなディレクトリを曖昧な状態に置く。そのディレクトリには Apache 2 の LICENCE.md がないからで、package.json フィールドを権威あるものと見なすなら 話は変わるかもしれない

  • UI は コントラスト を除けば Github より良く見える。アクセシビリティについては分からない

  • ちなみに Github のすべての pull request は末尾に .diff を付けると diff を取得できる
    例: https://github.com/oven-sh/bun/pull/30412.diff
    .patch を付けると git am に渡せる形式も取得できる: https://github.com/oven-sh/bun/pull/30412.patch

    • error: too big or took too long to generate
      この理由でわざわざこの PR を選んだの? :D
  • ツールに対する期待値が他の人より低いのかもしれないが、これを Github 自体の機能と比べたときの 実用的な違い がよく分からない
    みんな Github がどれだけひどいか嘆いているが、私は同じ体験をしたことがない。なぜ Github の代わりにこれを使うべきなのか分からない

    • なぜこれが自分にとって重要なのかを示す動画を録画した。動画が X にあって申し訳ないが、そこに上げてある
      歴史的にこれが自分の一般的な体験で、なぜ速度が重要なのかも説明している。ある作業が十分長く遅いと、考えが別のところへ流れてしまい、それが 没入状態 を大きく損なう
      動画では PR を開いて特定のファイルへ移動するまでの時間を並べて比較している。自分にとってはかなりよくある日常的な作業だ
      https://x.com/mitchellh/status/2057229385963618787
  • pulldash(coder.com 製) や difit(localhost ページを立ち上げる CLI) とかなり似て見える
    どちらもあまり気に入っていない。pulldash は少しもたつき、difit は追加の手間が必要だった。セルフレビューには今 git tree compare の VSCode 拡張を使っている
    これは速く、全体的なビジュアルデザインも気に入っている。自分の PR でひとつ試してみたが十分良さそうで、PC にブックマークしておいてもよさそうだ