GitUI: the Rust terminal git client, and where it stops

What GitUI is for, and who keeps hitting its ceiling

The README's motivation section is unusually direct about the target user. The author writes that he does most git work in a terminal but kept reaching for a GUI for the index, commit, diff, stash, blame and log, and that popular git GUIs "all fail on giant repositories or become unresponsive". GitUI is the response: a terminal UI that keeps the GUI interaction model, hunk-level staging and a diff pane, without the Electron or Qt layer that makes those tools stall on a repository with hundreds of thousands of commits.

So the audience is narrow and specific. It is someone who lives in a terminal, already knows git's model, and wants to stop typing `git add -p` and `git stash list` by hand. It is not aimed at people who want a visual branch graph, because that does not exist yet, and it is not aimed at people who want to avoid the command line entirely. The README says plainly that the tool "does not fully substitute the git shell" and that both work well in tandem.

The asyncgit workspace and why the UI stays responsive

The repository is a Cargo workspace, not a single crate. Alongside the `gitui` binary there are members `asyncgit`, `filetreelist`, `git2-hooks`, `git2-testing` and `scopetime`. That split is the architecture in miniature: `asyncgit` holds the git operations and runs them off the UI thread, `filetreelist` handles the status tree, and `scopetime` is a small timing helper the project uses to measure its own operations.

The dependency list confirms the rest. `ratatui` with the `crossterm` backend draws the interface, `crossbeam-channel` carries messages between the git worker and the render loop, and `notify` with `notify-debouncer-mini` watches the working directory so the status view updates when files change outside the tool. The README calls this an "async git API for fluid control", and the benchmark table in the README is where that claim is quantified: parsing the Linux git repository, which the README says contains over 900k commits, is listed at 24 seconds and 0.17 GB of memory for gitui, against 57 seconds and 2.6 GB for lazygit and 4 minutes 20 seconds and 1.3 GB for tig. Those numbers come from a RustBerlin meetup presentation, not from an independent benchmark, so treat them as the author's own measurement on one repository.

Installing GitUI from a package manager or release binary

The README lists package manager instructions for Arch Linux, Fedora, Gentoo, openSUSE, Homebrew and MacPorts on macOS, Winget, Scoop and Chocolatey on Windows, plus Mise, Nix, Termux and conda-forge. On macOS the shortest path is Homebrew:

brew install gitui

On Arch the package is in extra, so a single pacman call is enough:

pacman -S gitui

Windows users can use Winget, Scoop or Chocolatey; the README gives all three, for example:

winget install gitui

If your distribution is not in the list, the README points to release binaries on the GitHub releases page, with Linux builds for x86_64 (musl, statically linked), aarch64, arm and armv7. Building from source is supported through the Makefile, which targets `cargo build --release --locked` and requires the Rust version pinned in `rust-toolchain.toml`; `Cargo.toml` sets `rust-version = "1.88"`. Note that the README describes GitUI as being "in beta", so a package lagging a release behind is normal rather than a sign of abandonment.

A first session: staging a hunk and stashing

Once installed, run the binary from inside a repository. The Makefile's argument variable shows the shape of the flags the tool accepts, including `-d` for a repository directory and `-w` for a working directory, which is useful when you want to point GitUI at a bare repository or a checkout elsewhere on disk:

gitui -d ~/code/extern/kubernetes

The README states the control scheme is keyboard only, with context-based help so you do not have to memorize hot keys. In practice you open the status tab, move through the file tree, and expand a file to see its hunks; staging a single hunk rather than a whole file is the workflow the README names as one of the reasons the tool exists. From the same interface you can commit or amend, and the hooks listed in the features section (`pre-commit`, `commit-msg`, `post-commit`, `prepare-commit-msg`) run as they would from the shell.

Stashing is the other operation the README singles out. The stash view supports save, pop, apply, drop and inspect. If you prefer vim-style navigation, the repository ships `vim_style_key_config.ron` at the top level and a `KEY_CONFIG.md` file describing the key configuration format; the default bindings are documented in the README's key bindings section.

What GitUI does not do: rebase, git-lfs, sparse checkouts

The limitations are stated by the project itself, which makes them easy to weigh. Interactive rebase is not implemented; it sits in the roadmap section as a goal before 1.0, linked to issue #32. The same roadmap lists visualizing the branching structure in the log tab as unfinished, linked to issue #81. So if your workflow is squash-and-reorder before every push, GitUI is the wrong tool and you will drop back to the shell mid-task.

The known limitations section adds two more. There is no sparse repository support (issue #1226), and no git-lfs support (issue #2812). The second one is easy to miss until it bites: on a repository that stores large assets through git-lfs, the files GitUI shows you are pointers, not content. GPG commit signing is listed as supported but with shortcomings, pointing at issue #97, so signed-commit workflows deserve a test before you rely on them. There is also a configuration requirement rather than a bug: for HTTPS remotes, `credential.helper` needs to be explicitly configured (issue #800), which means a fresh machine with no credential helper set up will fail to push from inside GitUI.

GitUI against lazygit and tig

The obvious comparison is lazygit, and the README invites it by putting both in the same benchmark table. The difference the project claims is resource behaviour on very large histories: the table shows gitui completing the Linux repository parse in 24 seconds at 0.17 GB, lazygit at 57 seconds and 2.6 GB, tig at 4 minutes 20 seconds and 1.3 GB. The README also records freezes and crashes for the other two and none for gitui in that run. Those are single-run figures from a conference talk, so the honest reading is that the author measured his own tool winning on his own workload, and that memory footprint on giant repositories is the axis where the gap is largest.

Where the comparison turns against GitUI is feature coverage. lazygit and tig are mature enough that interactive rebase is not a roadmap item for them, and tig's binary is listed at 0.6 MB against 10 MB for gitui, which matters if you install tools on servers. GitUI's answer to the missing pieces is the tandem workflow the README describes: do the hunk staging, stashing and log browsing in the TUI, and drop to the git shell for rebase.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-04. Releases are infrequent rather than constant: v0.28.0 landed on 2025-12-14, v0.28.1-rc.1 on 2026-03-21 and v0.28.1 on 2026-03-24. The README describes GitUI as "a spare time project", which is the right frame for planning: expect feature work to arrive in bursts, and do not schedule around a roadmap item landing by a particular date.

Upgrade cost is low for most users. If you install through a package manager, you get whatever your distribution ships. If you build from source, the workspace pins its toolchain and the Makefile's release target uses `--locked`, so a rebuild is reproducible against `Cargo.lock`. The licence is MIT, declared in `Cargo.toml` and in `LICENSE.md`, which permits commercial use and modification; the usual obligation is preserving the copyright notice and licence text in distributions. That is a description of the licence terms, not legal advice, and if you redistribute a modified binary you should read the file yourself.

Editorial conclusion

Adopt GitUI if you stage hunks, stash and browse history on repositories large enough that a GUI lags, and you are willing to keep the git shell open beside it. Do not adopt it if your daily work depends on interactive rebase, git-lfs, sparse checkouts or a visible branch graph; the README lists all three as missing or roadmap items. Verify first that your platform package is current, that credential.helper is explicitly configured for HTTPS remotes, and that your git version satisfies the 1.88 Rust toolchain if you build from source.

Frequently asked questions

Official sources

1. gitui-org/gitui on GitHub
2. Issues
3. License: MIT
4. README
5. Releases