# keifu review: a Rust TUI for reading Git commit graphs

> keifu is a Rust terminal UI that draws a colour-coded commit graph and covers everyday Git operations. It is deliberately not a full Git client, and the README is explicit about the ceilings.

**trasta298/keifu** — Git genealogy, untangled. A TUI for navigating commit graphs with color and clarity.

- Repository: https://github.com/trasta298/keifu
- Stars: 806 · Forks: 25
- Language: Rust
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/trasta298-keifu

## What keifu is for, and who it leaves out

The README opens with the problem it wants to fix: `git log --graph` is hard to read. keifu renders the same history as a Unicode graph with per-branch colours, then puts commit metadata and changed-file stats next to it. The stated motivation is branch switching during parallel work, which the README ties to what it calls vibe coding: several branches open at once, and a checkout every few minutes.

The scope is narrow on purpose. The README says only basic Git operations are supported and that keifu is not a full-featured Git client. There is no rebase, no cherry-pick, no revert, no stash, no hunk-level staging, and no history rewriting of any kind. If your workflow depends on any of those, keifu is a viewer with a few write actions bolted on, and you will keep a second tool open.

Two design choices shape who gets value from it. First, no image protocol is required: the graph is drawn with Unicode line characters and colour, so it runs in any terminal with Unicode support. Second, it is built for narrow terminals, which the README lists as a motivation, so split panes and small windows are a supported case rather than an afterthought. That combination points at people who live in tmux or a terminal split and want the graph in one of those panes.

## How the graph, the panels and the data flow fit together

keifu is a single Rust binary. Cargo.toml shows the stack: ratatui 0.29 and crossterm 0.28 for the terminal layer, git2 0.19 with the vendored-openssl feature for repository access, similar 2.7 for diffs, syntect 5.2 for syntax highlighting, fuzzy-matcher 0.3 for the branch search, and toml 0.8 with serde for configuration. Repository reads go through libgit2 rather than shelling out, which is why the README lists `git` in PATH as a requirement only for fetch and push.

The layout is a graph pane and a detail pane, with a file diff view opened on top. The commit list carries branch labels, date, author, short hash and message, and the README warns that some fields may be hidden on narrow terminals. The detail panel shows the full message and changed-file stats with plus and minus counts. Pressing Space opens the file diff view, which uses syntect for highlighting and similar for word-level change emphasis.

Two graph behaviours are worth knowing before you trust the picture. When several branches point at the same commit, the label collapses to one name with a `+N` suffix, for example `main +2`, and you cycle between them with h and l. Remote branches are shown by default; pressing o hides them, and the README states that when hidden, commits reachable only from remote branches are excluded from the graph. The view is therefore a function of two toggles, not a fixed rendering of the repository.

## Installing keifu and taking it for a first run

The README gives four install paths. The crates.io route is the shortest if you already have a Rust toolchain:

```bash
cargo install keifu
```

mise users can install the published binary directly, and Homebrew users can pull from the project's tap:

```bash
mise use -g github:trasta298/keifu@latest
```

```bash
brew install trasta298/tap/keifu
```

Building from source is the fourth option, and it clones the repository before installing the binary from the working tree:

```bash
git clone https://github.com/trasta298/keifu && cd keifu && cargo install --path .
```

There is no configuration step required to start. Change into any Git repository and run the binary with no arguments:

```bash
keifu
```

The README states that keifu discovers the repository from the current directory, so it must be run inside one. What you should see is the graph pane on the left with colour-coded branch lines, the commit list, and the detail pane for the selected commit. Press ? for the help overlay, Tab to move focus between graph and detail, and Space to open the file diff view for the selected commit. If there are staged, unstaged or untracked changes, an uncommitted changes row appears at the top of the list; selecting it and pressing s stages the highlighted file, and c opens the commit message dialog. Configuration lives in a separate document, docs/configuration.md, which the README links but does not reproduce.

## The ceilings the README states plainly

keifu loads up to 500 commits across the visible branches. That is a hard cap, and it is the first thing to check against your repository: on a long-lived branch with dense history, the graph you see is a window, not the whole story, and the README does not describe a way to raise the limit from the interface.

Changed files are capped at 50 per commit, and binary files are shown without line stats. A commit that touches a generated directory or a lockfile will therefore give you a truncated file list, and the plus and minus counts you see in the detail pane cover only what fits.

Merge commits are diffed against the first parent only, and the initial commit is diffed against an empty tree. For a merge that resolves conflicts, the diff you get is the change relative to one side of the merge, not a combined view. Nothing in the README suggests a way to switch parents.

Staging is per file. There is no hunk-level staging, and commits include only staged changes, which the README compares to plain `git commit`. If your workflow depends on splitting a file's changes across two commits, keifu cannot do it.

Delete only works on local, non-HEAD branches. Fetch and push require the origin remote to be configured, so a repository whose main remote has another name will not fetch or push from inside keifu. Checking out origin/xxx creates or updates a local branch, upstream is set only when creating a new branch, and if the local branch exists but points elsewhere it is force-updated to match the remote. That last behaviour is a destructive default worth reading twice before you press Enter on a remote branch.

## Where keifu sits next to lazygit and gitui

lazygit and gitui are the obvious comparisons, and the difference is one of intent rather than feature count. Both of those are full Git clients in a terminal: staging at hunk granularity, rebase, stash, cherry-pick and conflict resolution are part of the surface. keifu is a graph viewer with a small set of write operations, and the README says so directly.

That split shows up in the rendering too. lazygit and gitui present panels of lists and menus; keifu's central artefact is the commit graph itself, drawn with per-branch colours and navigable with `]` and `[` to jump between commits that carry branch labels, and `@` to jump to HEAD. If your question is where a branch diverged, keifu answers it faster. If your question is how to reshape three commits into one, none of keifu's keybindings apply.

There is also a plumbing difference. keifu reads through libgit2 via git2, while lazygit is built around invoking the `git` binary. The practical consequence stated in the README is that keifu needs `git` in PATH only for fetch and push, so the rest of the interface works even where the command-line Git is missing or unusual. That matters in minimal containers more than it does on a developer laptop.

The honest framing is that keifu does not replace either tool. A team already comfortable in lazygit gains a clearer graph and loses every history-editing operation by switching. Running keifu for inspection alongside a full client is the arrangement its feature list actually supports.

## Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-07-30, which is also the date of the v0.6.0 release. The two releases before it, v0.5.0 and v0.4.0, landed on 2026-06-19 and 2026-06-10, so the recent cadence is a release roughly every few weeks over that stretch. That is a data point about activity, not a promise about the next six months.

keifu is MIT licensed, which is permissive and compatible with commercial use; the repository carries a LICENSE file at the top level. The dependency list is worth noting for anyone who has to audit a binary: git2 pulls in libgit2 and, with the vendored-openssl feature, builds OpenSSL from source rather than linking the system copy. That makes builds self-contained but slower, and it means an OpenSSL advisory reaches you through a keifu release rather than through your distribution's package manager. syntect, similar and ratatui carry their own licences, which the README does not enumerate.

Upgrade cost is low by design. The release profile in Cargo.toml sets lto, codegen-units = 1 and panic = "abort", so release builds are optimised rather than fast to compile. Configuration is read from a TOML file documented in docs/configuration.md, and the README does not describe a migration procedure between versions, so a config written for an older release is not guaranteed to keep working. Pin the version in CI if you script keifu, and read the release notes for the version you are moving to.

## Conclusion

keifu suits engineers who work across several branches at once and want the graph to be legible without leaving the terminal; it is a poor fit for anyone who needs hunk-level staging, interactive rebase or history rewriting, because the README lists none of those. Before adopting it, run keifu in a scratch clone and confirm the 500-commit cap and the 50-file diff cap do not clip the repository you actually work in, and check whether your terminal handles OSC 52 clipboard writes if you rely on y and Y.

## FAQ

### How do I install keifu?

The README lists four routes: `cargo install keifu` from crates.io, `mise use -g github:trasta298/keifu@latest`, `brew install trasta298/tap/keifu`, or cloning the repository and running `cargo install --path .` from inside it.

### Does keifu support hunk-level staging?

No. The README states that staging works per file and that there is no hunk-level staging, and that commits include only staged changes, like plain `git commit`.

### How many commits does keifu load?

The README states that the TUI loads up to 500 commits across the visible branches, and that changed files are capped at 50 per commit with binary files shown without line stats.

### Why does keifu need the git command in PATH?

According to the README, `git` in PATH is required for fetch and push. Repository reads go through libgit2 via the git2 crate, so the rest of the interface does not depend on the command-line binary.

## Sources

- [Official README](https://github.com/trasta298/keifu#readme)
- [Project repository](https://github.com/trasta298/keifu)
- [Release notes](https://github.com/trasta298/keifu/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trasta298-keifu