GitUI

Original Article ↗ Hacker News Discussion ↗

GitUI, a terminal-based Git interface written in Rust, is praised for being fast, lightweight, and well-suited to very large repositories where many traditional Git GUIs or TUIs become slow or unresponsive. Commenters compare it extensively to tools like lazygit, tig, magit, and various graphical clients, weighing trade-offs in performance, feature completeness (e.g., interactive rebase, LFS, sparse checkouts), usability, and keyboard-centric workflows. The conversation also touches on Rust as a selling point, packaging challenges on distributions like Debian, and broader preferences for visual Git tools versus the command line or IDE integrations.

Performance and scalability

  • GitUI is positioned as a terminal UI that stays responsive on very large repos where many GUIs allegedly “fail” or freeze.
  • A benchmark on the Linux kernel repo (≈900k commits) shows GitUI much faster and far more memory-efficient than lazygit and tig, with fewer freezes/crashes.
  • Some question whether these gains matter on typical, smaller projects; others find the memory savings more compelling than raw speed.
  • There’s debate over whether Git performance problems are about UI vs git itself; some note issues happen when tools eagerly compute diffs, not just git status.
  • IntelliJ’s Git UI is cited as performant due to heavy indexing and caching; in contrast, many Git tools (including CLI) avoid caching by design, which is seen by some as a feature, others as a solvable problem.

Feature set and comparisons

  • GitUI is often compared to lazygit, tig, magit, and IDE integrations.
  • Some see it as a near-feature-parity rewrite of lazygit “in Rust,” even missing features like interactive rebase (a libgit2 limitation), LFS, sparse checkouts, and commit signing support.
  • Others prefer GitUI’s interface and Vim-style keybindings despite lazygit having slightly more features.
  • Users value GitUI mainly for quick reviewing/staging of changes and as a daily driver for common operations.

Rust, binaries, and packaging

  • “Written in Rust” is discussed as both marketing and a genuine selling point: people associate Rust tools with speed, memory safety, and high-quality single-binary distributions.
  • It’s noted that GitUI relies on libgit2 (C) for heavy lifting and that Rust binaries aren’t always fully static; some users often end up building from source.
  • Absence from Debian repositories triggers a side discussion: Debian packaging is considered complex and slow-moving; Rust’s fast evolution can clash with Debian’s older toolchains. Tools exist to generate .deb packages, but getting into Debian is seen as a longer, more involved process.

UX: keyboard, mouse, and visualization

  • GitUI emphasizes “keyboard-only” control; some users miss mouse support for things like pane resizing and see terminal mouse input (as in Vim) as a major usability boost.
  • TUIs are praised for efficient keyboard workflows but criticized for lower information density and layout rigidity compared to full GUIs.

Why use a Git UI at all?

  • Many comments broaden to Git GUIs/TUIs in general:
    • Easier staging/unstaging of hunks or individual lines.
    • Visual commit graphs and rebase/merge operations without memorizing hashes.
    • Faster cherry-picking, branch switching, and blame navigation.
    • Always-visible repository state (branches, untracked files, recent commits).
  • Some rely on GUIs or editor integrations for review and basic operations, using CLI for advanced tasks.
  • A concern is that some UIs hide the underlying git commands and flags, making debugging harder; others praise tools that explicitly show the exact commands they run.