GitUI 技術関連ニュース

 (github.com/extrawurst)
10 ポイント 投稿者 GN⁺ 2024-01-08 | 1件のコメント | WhatsAppで共有
  • GitUIは、ターミナル内で Git GUI の使いやすさと利便性を提供するツールで、大規模リポジトリで既存の Git GUI が固まったり遅くなったりする問題を経験したユースケースから始まった
  • 主な機能には、キーボードのみの操作、コンテキストベースのヘルプ、変更内容の検査・コミット・amend、ファイル・hunk・line 単位の stage/unstage/revert/reset、stash、push/fetch、ブランチ管理、コミットログ検索と diff 確認が含まれる
  • Linux Git リポジトリの 90万件以上のコミットをパースした比較では、gituiは24秒、メモリ0.17GBを記録し、lazygitは57秒・2.6GB、tigは4分20秒・1.3GBを記録した
  • 1.0 前の目標には、ログタブでのブランチ構造の可視化と interactive rebase があり、git-lfs、sparse repo、HTTPS 用 credential.helper の自動処理には既知の制限がある
  • 現時点では Git shell を完全に置き換えるものではなく、stash や line・hunk 単位の staging のように Git shell では不便な作業を補完する形で併用するツールに近い

Git GUI 体験をターミナルへ持ち込むツール

  • GitUIは、ターミナルで Git GUI のユーザー体験と利便性を提供するオープンソースツール
  • 開発の動機は、ターミナルでほとんどの Git 作業を行いながらも、index、commit、diff、stash、blame、log などの作業では Git GUI を頻繁に使うようになった経験にある
  • 既存の人気 Git GUI には、大規模リポジトリで失敗したり応答しなくなったりして、使えなくなる問題があった
  • GitUI は、ターミナル内で portable、fast、free、opensource な Git GUI 体験を目指している

機能範囲

  • 操作モデルはキーボードのみの制御とコンテキストベースのヘルプを中心としており、多くのショートカットキーを覚える必要がないように設計されている
  • 変更内容に関する作業には以下が含まれる
    • 変更内容の inspect、commit、amend
    • pre-commit、commit-msg、post-commit、prepare-commit-msg フックを含む
    • ファイル、hunk、line 単位の stage、unstage、revert、reset
  • リポジトリのフロー作業もサポートする
    • stash の保存、pop、apply、drop、inspect
    • remote への push、remote からの fetch
    • ブランチの作成、名前変更、削除、checkout、remotes の表示
    • コミットログの閲覧と検索、コミット済み変更内容の diff 確認
  • UI と内部動作には、レスポンシブなターミナル UI、滑らかな操作のための非同期 Git API、submodule サポートが含まれる
  • GPG commit signing はサポートするが、#97 に関連する制約がある

ベンチマーク結果

  • RustBerlin meetup の発表で、lazygit、tig、gituiを Linux Git リポジトリ全体のパースで比較した
  • 比較結果は以下の通り
    • gitui: 24秒、0.17GB メモリ、10MB バイナリ、freeze なし、crash なし
    • lazygit: 57秒、2.6GB メモリ、25MB バイナリ、freeze あり、crash は時々発生
    • tig: 4分20秒、1.3GB メモリ、0.6MB バイナリ、freeze は時々発生、crash なし
  • gituiは、この比較で時間とメモリの項目において最も低い値を記録した

1.0 前のロードマップと既知の制限

  • 1.0 と呼ぶ前の上位目標は2つある
    • ログタブでのブランチ構造の可視化: #81
    • interactive rebase: #32
  • 現在の制限には以下が含まれる
    • git-lfs 未サポート: #2812
    • sparse repo 未サポート: #1226
    • HTTPS では credential.helper を明示的に設定する必要がある: #800
  • GitUI は現時点で Git shell を完全に置き換えるものではなく、2つのツールを併用する形が適している
  • 優先順位は、stash、line・hunk 単位の staging のように Git shell では不便な機能に置かれている
  • プロジェクトは現在 spare time project であり、GitUI を one stop solution にするには支援が必要

インストールとビルド

  • GitUI はbeta状態であり、バグや未実装の機能がある可能性がある
  • 個人利用には妥当に安定しており、GitUI 自体の開発にも使われている
  • 複数のパッケージマネージャーでインストールできる
    • Arch Linux: pacman -S gitui
    • Fedora: sudo dnf install gitui
    • openSUSE: sudo zypper install gitui
    • Homebrew: brew install gitui
    • MacPorts: port install gitui
    • Winget: winget install gitui
    • Scoop: scoop install gitui
    • Chocolatey: choco install gitui
    • Mise: mise use -g gitui@latest
    • Termux: pkg install gitui
    • Anaconda: conda install -c conda-forge gitui
  • リリースバイナリは Linux、macOS、Windows 向けに提供される
    • Linux には x86_64、aarch64、arm、armv7 パッケージがある
    • macOS には arm64 と Intel x86 パッケージがある
    • Windows には 64bit の単一バイナリと 64bit MSI インストーラーパッケージがある
  • ビルド要件は以下の通り
    • 最小サポート rust/cargo バージョンは1.88
    • OpenSSL 依存関係のビルドには perl 5.12 以上と C コンパイラが必要
    • テストスイート全体の実行には、pythonとして呼び出せる Python が必要
  • Cargo では cargo install gitui --locked コマンドでビルドとインストールを開始できる
  • trace-libgit Cargo feature は libgit2 tracing を有効化し、libgit2 が -DENABLE_TRACE=ON でビルドされている場合に動作する
  • この feature はデフォルトで有効化されており、無効化するには cargo install --no-default-features を使う

設定、診断、カスタマイズ

  • ロギングは gitui -l で有効化する
  • ログファイルの場所はプラットフォームごとに異なる
    • macOS: $HOME/Library/Caches/gitui/gitui.log
    • Linux with XDG: $XDG_CACHE_HOME/gitui/gitui.log
    • Linux: $HOME/.cache/gitui/gitui.log
    • Windows: %LOCALAPPDATA%/gitui/gitui.log
  • GitUI は light と dark の両方のターミナルテーマで自動的に動作するはず
  • カラーテーマは THEMES.md に従って好みに合わせてカスタマイズできる
  • キーバインドは KEY_CONFIG.md に従ってカスタマイズでき、vim スタイルのバインドに設定できる
  • インスピレーション元として挙げられているプロジェクトは lazygit、tig、GitUp、git-brunch
  • GitUp については、ターミナルツールで map view を使う方法を見つけられるとよい、という目標が付け加えられている

関連記事

1件のコメント

 
GN⁺ 2024-01-08
Hacker News の意見

  • インストールしてすぐ、xterm ウィンドウが小さすぎたので大きくし、ファイルツリー領域の端をドラッグして縮めようとしたができなかった
    diff をもっと大きく見たかったし、ファイル名も短くてツリー領域の大半が無駄になっていたのに、H のヘルプにも関連するキーがなく、キーボードでもサイズ調整できないようだった
    たとえキーボードで可能だとしても、このような場合はマウスでのリサイズのほうがずっと簡単で速いし、壊れた SSH 環境のようにマウスが使えないときのためにキーボードでの調整もあるとよい

    • キーボードショートカットにターミナルのマウス対応を補完するのは本当に有用
      Vim でもトラックパッド/マウスを今でも使う場面はスクロールとウィンドウサイズ調整で、SSH 越しでもその両方を提供できない理由はない
      ここにもよい追加機能になりそう

  • lazygit がこのプロジェクトの着想元として書かれているが、lazygit ユーザーとしては、完全に新しいプロジェクトが必要になるほど何が足りなかったのか気になる
    lazygit はとても便利に使っている

    • その方法論が妥当かどうかは判断しにくいが、マネージャーの目線で見ると数値はかなり印象的
      RustBerlin ミートアップの発表用に Linux の Git リポジトリ全体をパースして lazygit、tig、gitui を比較しており、そのリポジトリには90万件以上のコミットがあった
      gitui は24秒、メモリ0.17GB、バイナリ1.4MB、フリーズなし、クラッシュなしで、lazygit は57秒、2.6GB、16MB、フリーズあり、たまにクラッシュ、tig は4分20秒、1.3GB、0.6MB、たまにフリーズ、クラッシュなしだった
    • 何年も lazygit を毎日使っていて、数か月前にこれも試したが、ほぼ完璧なツールを Rust で書き直すために作られた事例のように見えた
      記憶では lazygit にない機能はなく、むしろ lazygit にある一部の機能が欠けていた
    • README に動機が書かれている
      ほとんどの Git 作業はターミナルで行うが、index、commit、diff、stash、blame、log のような用途では Git GUI をよく使うようになり、人気のある Git GUI は巨大なリポジトリで失敗したり応答しなくなったりして使えなかったという

  • 「人気のある Git GUI は巨大なリポジトリで失敗したり応答しなくなったりして使えない」という話は、.gitignore にまだ入れていない非常に深いディレクトリツリーのせいで git status がコマンドラインや magit で時間がかかるときにしか見たことがない
    こういう場合は GUI/TUI/コマンドライン Git の使用間に差はないと思う
    他の Git インターフェースは Git 自体よりも劇的に失敗するのだろうか？

    • Magit の失敗のしかたは、status ページでdiff 情報を取得する下位動作が原因だと思う
      同じ問題があったときでも、コマンドラインの git status はほぼ即座に終わった
      多くの情報を表示するには時間が必要なのは避けられないが、magit は一部の箇所で eager に動きすぎて、生の Git フローよりはるかに高コストなワークフローを作ることがある
    • 大きな merge は magit では絶対にやらず、そういうものには Git CLI を使う
    • それなら意外だ
      IntelliJ の Git UI は Java で書かれて IDE 内に組み込まれているのに十分速いので、外部 Git UI なら問題ないはずに思える

  • 関連記事:
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - 2022年9月、コメント90件
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - 2020年12月、コメント1件

  • Git でクリック＆ドラッグ UIを作った人はいる？
    ブランチをただドラッグ＆ドロップするような形で作業できる UI のこと

    • 一番好きな Git GUI は Fork: https://git-fork.com/
      merge、rebase、stage/unstage など複数の作業でドラッグ＆ドロップに対応していて、おそらく他にもあるはず
    • 基本的な作業には GitHub Desktop を使い、複雑なものは CLI を使う
      かなりシンプルな Git クライアントだが、コミットの cherry-pick などの操作に少しだけドラッグ機能がある
    • 宣伝機能の一つとしてそういうものを掲げている拡張機能を見たことはあるが、使ったことはない
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • 10年たっても、UI でクリック＆ドラッグが必要なときはいまだに主に SourceTree を使う

  • こういうツールはどれも試してみるが、いつも重要な機能が一つ欠けているか、望む形で動作しないので、結局 tig に戻ることになる
    GitUI では Log ビューのような場所でブランチ構造をうまく見せる表示を見つけられなかった
    rebase を考慮してブランチ構造をうまく見せてくれるツールがあるとよい

  • よさそうなので一度使ってみるつもり
    いつか GitExtensions がネイティブ Linux アプリケーションとして移植されることを願っている
    何十もの UI を使ってきたが、あれほどのものはないように思う

    • Linux に移ってから毎日恋しく思う唯一の Windows アプリは TortoiseGit
      コンテキストメニューベースのシステムを TortoiseGit のように自然に使わせてくれる Git UI はまだなかった
    • GitExtensions を知っている開発者がこんなに少ないことにはいつも驚く
      それに近い別の Git UI は Tortoise だけだが、以前 hg 版だけを使ったことがある
    • Gitex は素晴らしい
      Linux で今でも 2.x mono 版を使っている

  • 約1か月前から使い始めた Neovim プラグイン neogit と非常によく似ている
    キーバインドは少し粗く、全体のワークフローに本当に慣れるまで1時間ほどかかったが、慣れてからは以前のやり方、つまり neovim を suspend してシェルで Git を直接使うよりずっと速くなった
    0: https://github.com/NeogitOrg/neogit

  • UI ツールについて心配な点の一つは、実際のコマンドをユーザーから隠してしまうことが多く、あとで何がまずかったのか、今後どう避けるべきかを推測しにくいこと
    たとえば、あるツールは通常の CLI フローに合わないかなり独断的なフラグを付けることがある
    このツールにも当てはまるかは分からないが、この種のツールには興味深いフィードバックになり得る

    • だから Windows では GitExtensions を使っていて気に入っている
      実行するコマンド全体を常に表示してくれ、ログ全体も完全に見ることができる