DiffsHub
(diffshub.com)- 大規模な GitHub diff をブラウザで素早く見渡したいとき、DiffsHub は公開 diff を 仮想化インターフェース で表示するツール
- GitHub URL の
github.comをdiffshub.comに置き換えると、PR、比較、コミット、diff、patch の変更内容をすぐに見られる - 別途変換手順なしで既存の URL 構造を維持し、
github.com/org/repo/pull/numberをdiffshub.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/numberdiffshub.com/org/repo/pull/number
数百万行 diff と制約
- DiffsHub は数百万行規模の比較も扱える
- 例として Linux v6.0...v7.0 の比較 を見られる
- こうした大規模比較は モバイルブラウザ で時々クラッシュすることがある
- GitHub は 100k 行超の diff を、最初のバイトが遅延した状態で不安定に提供することがある
1件のコメント
Lobste.rs の意見
diff 表示と vibecoding タグ がどう関係するのか理解しようとしていた
その後、文脈と経緯を追って、なぜこうなったのか理解した。騒ぎを起こして @quad に申し訳ないし、今はタグも外されたのを確認した
たとえばコード品質が低い、コミット数が少ない、果てはリポジトリに CLAUDE.md があるという理由だけで vibecoding タグを付けていて、あまり意味がないように見える
追加の文脈としてはこの記事が関係ありそう: On Rendering Diffs
ホームページにリンクされた Linux diff を見て回るときもかなり滑らかで印象的。スクロールバーを直接ドラッグしてみれば分かる。Github や他のブラウザベースの diff エディタ、職場で使っている Graphite もこのくらい滑らかだったらいいのにと思う
一方で、こんなことに感心している事実自体がおかしい。本来これが標準であるべきではないかと思う
文字どおり数か月のフルタイム業務が diff を高速にレンダリング できるようにすることだった
ちなみに “vibecoding” タグが付いていたが、やはり理解できないし、この作業はまったくそういう類いではなかった。大半は困難な調査、ブラウザ実装コードの読解、試行錯誤、問題を正攻法で掘り下げることだった
非常に狭く、成果が明確な探索作業にはエージェントループが使われたが、私の知る限り人間の洞察やレビューなしで投入されたものはなかった。ブログ記事でもこの点に触れているようで、全体の作業に占める割合は本当に小さかった。その理由だけで 工学的努力 を矮小化するのは筋が通らない
ブログ記事を読むかコードを見ることを強く勧める。驚くべき仕事で、学ぶことが多い
自分で試すためにブックマークレットを作った: 残念ながら多くの 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.patcherror: too big or took too long to generateこの理由でわざわざこの PR を選んだの? :D
ツールに対する期待値が他の人より低いのかもしれないが、これを Github 自体の機能と比べたときの 実用的な違い がよく分からない
みんな Github がどれだけひどいか嘆いているが、私は同じ体験をしたことがない。なぜ Github の代わりにこれを使うべきなのか分からない
歴史的にこれが自分の一般的な体験で、なぜ速度が重要なのかも説明している。ある作業が十分長く遅いと、考えが別のところへ流れてしまい、それが 没入状態 を大きく損なう
動画では PR を開いて特定のファイルへ移動するまでの時間を並べて比較している。自分にとってはかなりよくある日常的な作業だ
https://x.com/mitchellh/status/2057229385963618787
pulldash(coder.com 製) や difit(localhost ページを立ち上げる CLI) とかなり似て見える
どちらもあまり気に入っていない。pulldash は少しもたつき、difit は追加の手間が必要だった。セルフレビューには今 git tree compare の VSCode 拡張を使っている
これは速く、全体的なビジュアルデザインも気に入っている。自分の PR でひとつ試してみたが十分良さそうで、PC にブックマークしておいてもよさそうだ