ハクソク

世界を動かす技術を、日本語で。

Jjui – 呪術のための素晴らしいTUI

365日前原文(github.com)

概要

Jujutsu UI (jjui) は、 Jujutsuバージョン管理システム 用のターミナルユーザーインターフェース。 直感的な操作や豊富な機能で 効率的なバージョン管理 を実現。 Homebrew、AUR、Nix、Go install など多様なインストール方法に対応。 最低対応バージョンはv0.21+。 機能追加やコントリビューション も歓迎。

Jujutsu UI (jjui) の特徴

  • Jujutsuバージョン管理システム 用TUIツール
  • 個人ニーズ に基づく開発、今後も新機能追加予定
  • フィーチャーリクエストやコントリビューション 受け入れ

主な機能

  • revset切替機能
    • オートコンプリートやシグネチャヘルプ付きrevset変更操作
  • リベース
    • リビジョンやブランチを別のリビジョンへリベース
    • 詳細はRebase wiki参照
  • スカッシュ
    • 複数リビジョンを1つにまとめる操作
    • Sキーで実行、j/kで選択変更
  • リビジョン詳細表示
    • lキーで詳細ビュー表示
    • ファイル分割（s）、復元（r）、差分表示（d）など対応
    • 詳細はDetails wiki参照
  • ブックマーク
    • 選択リビジョンへのブックマーク移動
  • Op Logビュー
    • oキーでop logビューへ切替
    • rキーで選択オペレーション復元
    • 詳細はOp log wiki参照
  • プレビューウィンドウ
    • pキーでプレビュー表示
    • 選択項目に応じてjj show/diff/op showコマンド結果表示
    • スクロールやdiff表示など多彩な操作性
    • 詳細はPreview wiki参照
  • その他ショートカット
    • d: リビジョン差分表示
    • D: リビジョン説明編集
    • n: 新規リビジョン作成
    • s: リビジョン分割
    • a: リビジョン放棄
    • A: リビジョン吸収
    • e: リビジョン編集
    • g: Git push/fetch
    • u: 最後の変更を元に戻す
    • v: リビジョンのevolog表示

設定

  • 設定方法 はwikiのConfigurationセクション参照

インストール方法

  • Homebrew
    • brew install jjui
  • Archlinux (AUR)
    • paru -S jjui-bin または yay -S jjui-bin
  • Nix
    • nix-env -iA nixpkgs.jjui
    • 特定ブランチ/リビジョン利用時はflake対応
    • nix profile install github:idursun/jjui/main
  • Go install
    • 最新リリース版: go install github.com/idursun/jjui/cmd/jjui@latest
    • mainの最新コミット: go install github.com/idursun/jjui/cmd/jjui@HEAD
    • キャッシュバイパス: GOPROXY=direct go install github.com/idursun/jjui/cmd/jjui@HEAD
  • ソースからビルド
    • git clone https://github.com/idursun/jjui.git
    • cd jjui
    • go install ./...
  • プリビルドバイナリ
    • releasesページからダウンロード可能

互換性・コントリビューション

  • 最低対応Jujutsuバージョン: v0.21+
  • コントリビューション歓迎
    • プルリクエスト提出可能

Jujutsu UI (jjui) は、 直感的な操作性と豊富な機能 でJujutsuユーザーのバージョン管理を強力にサポート。 今後のアップデートやコミュニティ貢献 にも期待。

Hackerたちの意見

Hardcoreは、幸せを感じるツールを作ることを体現してるよね。個人的にはgitで全然大丈夫なんだけど、新しいVCSの周りにエコシステムを作ろうとする人たちがたくさんいるのを見ると、すごく刺激的だね。

└

Gitでの唯一の、そして最大の痛点は、小さなプロジェクトでも手動でのマージがたくさん必要になることなんだ。数週間や数ヶ月前のいくつかのブランチがあって、同じファイルのセットに触れることになる。結局、マージが承認されると、すべてのブランチでたくさんのコンフリクトを手動で解決しなきゃいけなくて、それを何度も繰り返すことになる。rerereは、少なくともリベースするすべてのブランチで同じマージを繰り返すのを防いでくれるはずなんだけど、私の経験では全然役に立たなかった。残念ながら、私の理解では、jjも不必要な手動マージの問題を解決してくれないみたい。

あ、これいいね！今週末にJujutsuを試してたんだけど、これが役立ちそう。まだオーバーフローの違いを理解しきれてないから、これで少し楽になるかも。

いいプロジェクトに見えるね！来週試してみるつもり。とりあえず、jjについての自分の考えを共有するね。ここにいるほとんどの人はjjを試したことがないと思うから。数ヶ月前からjjを使い始めたんだけど、GoogleにいたときはFigを使ってたんだ。その後2.5年以上はずっとgitだけを使ってて、jjを使うのは自転車に乗るみたいだったよ。自分が求めてるものにほぼぴったりで、できるだけ使ってる。とはいえ、いくつかの痛点があるんだ（それでもjjの方がgitより好きなんだけど）：

  • スタックのためのGitHub PR同期がない。スタックされたdiffをローカルで管理するのは素晴らしいけど、（もっと良いバージョンの）SaplingのPR同期があれば大きな価値になると思う。これは自分にとって直接的な痛点だけど、jjを社内で「スタックされたdiff」ソリューションとして広めようとしたときには、もっと弱点になるんだ（例えば、エンジニアリングツールチームに認められるために）。Saplingに詳しい人やjjに懐疑的な人は、この機能のギャップを指摘することで、ほぼ会話が終わっちゃうんだよね。
  • ネイティブバックエンドが変更のプッシュ/プルをサポートしてくれたらいいのに。ノートパソコンとワークステーションの間で作業を切り替えたいんだけど、GitHubにプッシュしたりプルしたりするのはjjの履歴が失われちゃうから明らかにダメなんだ。手動で.jjディレクトリをコピーするのは、注意して正しくやればうまくいくみたいだけど（つまり、.jjをコピーする時に両方のクローンが同じ作業コピーの状態であることを確認する）、これだと脆弱で、ミスしやすいんだよね。
  • 新しいrevを始めるのを忘れちゃうと、（自分やLLMが）リポジトリに触れる前に、変更を新しいrevに分けるのがちょっと面倒なんだ。
  • 自分が関わった成熟したリポジトリの中には、.gitの存在を探したり依存したりするツールやスクリプト、テストがあるみたいなんだ（間接的に）。コロケートされたリポジトリを使えばこれを回避できたかもしれないけど（つまり、git cloneしてからjj git init --colocate）、少なくとも一つのケースでは、jjを使うのを諦めて別のgitクローンを作っちゃったんだ。これはjjのせいというより、gitとの実用的な互換性のギャップだと思う（再度、--colocateを使えば完全に解決できるかも）。
└

スタックのためのGitHub PR同期がない。 これについては、クライアントのサポートが必要なことがGitHubの奇妙な欠点だと思う。GitHubがGerritのように個別のコミットをレビューできるようにしてくれれば、「PRスタッキング」の概念は必要なくなるはずだよ（Gerritのように）。「PRはただの変更の塊」というモデルは、コードレビューツールの赤ちゃんのおもちゃみたいなものだと思う！

└

スタックのためのGitHub PR同期がない。スタックされたdiffをローカルで管理するのは素晴らしいけど、（もっと良いバージョンの）SaplingのPR同期があれば大きな価値になると思う。これは自分にとって直接的な痛点だけど、jjを社内で「スタックされたdiff」ソリューションとして広めようとしたときには、もっと弱点になるんだ（例えば、エンジニアリングツールチームに認められるために）。Saplingに詳しい人やjjに懐疑的な人は、この機能のギャップを指摘することで、ほぼ会話が終わっちゃうんだ。これについて詳しく説明してくれる？自分はjjを使って、GitLabでjj git push --allを使ってスタックされたPRをやってるんだけど、Saplingは使ったことがないから、そのスタックされたPRのやり方には詳しくないんだ。何を欠いているのか、すごく気になるんだよね。

└

tangled.shに興味があるかもしれないよ。最近、jjとのスタックされたPRのサポートを追加したGitフォージなんだ。[1]: https://bsky.app/profile/tangled.sh/post/3lptwcb47kc2u

└

ネイティブバックエンドが変更のプッシュ/プルをサポートしてくれたらいいのに。 0.29.0がここに向けて進んでるみたいだよ。私の理解では、これは最初のステップに過ぎないんだけど（あまり詳しく追ってないから）： https://github.com/jj-vcs/jj/releases/tag/v0.29.0 git.write-change-id-header > 新しいrevを始めるのを忘れちゃうと、（自分やLLMが）リポジトリに触れる前に、変更を新しいrevに分けるのがちょっと面倒なんだ。これが今の自分の最大の痛点だね。これについては、もっと良いドキュメントがあれば部分的に解決できると思う。過去に少し貢献したけど、まだこの部分を見る時間がなかったんだ。

└

--colocateは確かに私にはうまく機能してるよ。バックエンドは実際の.gitディレクトリに保存されて、.jjディレクトリの奥深くに隠れているベアGitリポジトリではなくなる。pygitやConanのようなツールを使うPythonスクリプトは、その.gitディレクトリを安全に使えるし、jjのワークフローを楽しめるよ。ただ、Gitのワークツリーを使う習慣があると、jjのワークスペースにいくつか問題が出るかもしれないね。共存リポジトリがもうないから。

これはかなり良さそうなTUIだね！CLIには満足してるよ（特にfishだと自動補完が充実してるし）。でも、もしそれに満足できないなら、これもかなりいい感じ。JJについては、使い始めた頃に書いたことがあって、今は数ヶ月経って、ワークフローに欠かせない存在になってる。Gitは今見るとちょっと使いづらい感じがする（以前は特に問題なかったんだけどね）。jjがGitと互換性があるおかげで、もう自分で使う必要がなくなったのはラッキー。歴史的に自分のGit履歴にはあまり興味がなかったし、PRもいつもまとめてたけど、今はたまに良い説明をつけた空の変更を使って、自分のブランチにTODOリストみたいなものを書いてる（ちょっとCDD、Change-Driven Developmentみたいな感じ :) ）。全体的にすごくクリーンになったよ。いろんな実験や進行中の作業でGitでたくさんスタッシュを使ってたけど、今は普通のローカル専用のjj変更になった。スタッシュのリベースという厄介な問題も解決してくれるし。もしこのコメント欄を読んで、jjを試す価値があるかどうか迷ってるなら、ぜひ試してみることを強くおすすめするよ！

└

CDDのことを初めて聞いたけど、もう気に入ってる！

直接関係ないけど、jjに良いGUIがないのは驚きだね。たくさんのVCマネーが確立されたニッチを追いかけてる中で（例えば、bunからnodeへ）、jjには成長の可能性がたくさんあるのに。特に開発者の関心が高いし、ロックインが必要ないっていう利点もあるからね（jjリポジトリは普通のGitリポジトリに変換できる）。

└

jjがVCから資金提供されてないのは、たぶん良いことだね。

└

VSCodeユーザー向けには、https://github.com/keanemind/jjk があるよ。HelixやZedにjjサポートを追加するチケットもあるから、期待できるね。

└

jjは実質的にはGitのUIだね。誰も使ってない実験的なセルフホストのバックエンドがあって（リリースビルドでは無効になってる）、Googleにはpiperバックエンドがあるから、これで独自のVCSと呼ばれることもあるけど、jjを中間層として使わずにGitの上に同じプライミティブを構築する他のツールを作ることを妨げるものは何もないと思う。私の理解では、ある程度それがGitButlerだね。

└

https://github.com/jj-vcs/jj/wiki/GUI-and-TUI でスタンドアロンのGUIと2つのVS Codeプラグインを見てみて。そこにあるGUIは完全な機能を持ってるわけじゃないから、どんな風に進化するか想像しなきゃいけないこともあるけど、どれも使えるよ。2つのVS Codeプラグインは同時に使えるし、互いに補完し合う感じ。

機能的にこれほど簡単で完璧なものは、まだfossil以外には見つけてないよ。jjはGitの代わりとして何を解決しようとしてるのかな？

└

jjはGitの代わりというより、同じ基盤の上に新しいポーセリンを作った感じだね。JJはGitのバイナリを使って、Gitリポジトリを維持してる。共存モードでは、jjの作業コピーはGitの作業コピーになるよ。普通のGitツールを使うと、なぜデタッチドヘッドモードになってるのかちょっと不安になるかもしれないけど、読み取り専用のツールは問題なく動作するし、リポジトリに書き込むとjjが手動変更をきれいに吸収してくれるよ。

└

すべてのDVCSは結局同じことなんだよね。みんな同じデータ構造に対する人間インターフェースを提供してるだけ。これは軽視してるわけじゃなくて、人間インターフェースは非常に難しい問題で、たくさんのブレイクスルーが期待できるんだ（その中には面白いアルゴリズムも含まれる、pijulを見てみて）。だから、君の質問に答えると、jjはgitでできることを同じようにできるけど、（議論の余地はあるけど）UI/UXがずっと良いんだよ。

俺は約10年間Magitを使ってたんだけど、jjに切り替えたときはすごく寂しかった。やっぱり、こういうのがコミュニティにとって大きな助けになると思うし、いつか実現してほしいな。matkladがここで提案してるように、エディタに依存しない形でね。jjuiは、今まで試した中で一番好きなjjのTUIだよ。サクサク動くし、便利で直感的なキーバインドがあって、見た目もいいし、安定性も今のところ良好。ただ、周りのzellijやターミナルのペインをリサイズすると、ちょっと不具合が出るみたい。Lazyjjは、同じリポジトリで使ったらちょっと遅かったし、クラッシュしやすかった。jj-fzfは悲惨なbashの山だから、絶対に使うのはおすすめしない。

美しい作品だね。他のjjのTUIも試したけど、どれも使いにくくて直感的じゃなかった。このTUIは、jj logの出力をそのままインタラクティブにした感じがする。ちなみに、俺は何年もGitUpを使った後にjjに切り替えたんだけど、jj CLIを使ってもあんまり恋しくならなかったのが驚きだった。GitUpで好きだった機能は、jj CLIでかなりカバーされてるよ：

  • アンドゥ
  • インタラクティブなステージング（jjではjj split -iでインタラクティブスプリットに相当する）
  • DAGを直接操作してる感覚（jj rebase） 特に、jjはインタラクティブさが最も役立つ部分にTUIを組み込んでるのがいいね。