gitlogue: replaying Git commits as terminal animation

What gitlogue replays, and for whom

gitlogue is a Rust terminal application that takes commits from a Git repository and plays them back as an animation. The README describes it as "a cinematic Git commit replay tool for the terminal" and lists the visual elements: realistic typing, cursor movement, deletions, file operations, syntax highlighting and file tree transitions. The unit of playback is a commit, or a range of commits, not a live editing session.

The audience is narrower than the topic list suggests. The README names five use cases: a screensaver for your workspace, education, presentations, content creation with VHS or asciinema, and what it calls "look busy mode" during meetings. Every one of those is a viewing scenario. Nobody opens gitlogue to find out which commit broke a test. If you want the history itself, git log already does that, and gitlogue does not try to replace it.

The honest framing is that this is a rendering layer on top of history you already have. It reads the repository through git2 and draws it with ratatui and crossterm. It does not modify commits, and nothing in the README suggests it writes to the repository.

How the animation is built: git2, ratatui, tree-sitter

The dependency list in Cargo.toml tells you most of the architecture. git2 with vendored-openssl and vendored-libgit2 handles repository access, so gitlogue does not shell out to the git binary for reading history. ratatui and crossterm draw the terminal UI and handle key events. tree-sitter, one grammar crate per language, produces the highlighting: the README claims 32 languages, and Cargo.toml carries a matching set of tree-sitter-* crates from tree-sitter-astro-next and tree-sitter-bash through tree-sitter-zig.

Playback is a per-character animation. The --speed flag sets milliseconds per character, and --speed-rule overrides that per file pattern, so a slow Java file and a fast XML file can coexist in one replay. --ignore and --ignore-file drop paths you do not want on screen, such as notebooks or lock files. The README's own example combines them: gitlogue --commit HEAD~5 --author "john" --theme nord --speed 15 --ignore "*.ipynb".

The consequence of this design is that the animation is a reconstruction. gitlogue shows the diff of a commit typed out character by character; it is not a recording of how the code was actually written. That distinction matters if you plan to use it in teaching, because the typing rhythm is a presentation choice, not evidence about the author's process.

Installing gitlogue and replaying your first commit

The README marks the install script as the recommended path. It downloads and runs install.sh from the main branch of the GitHub repository.

curl -fsSL https://raw.githubusercontent.com/unhappychoice/gitlogue/main/install.sh | bash

If you would rather use a package manager, the README lists Homebrew, Cargo, pacman on Arch Linux, and Nix. The Cargo route is the one that also works for building from a checkout.

brew install gitlogue
cargo install gitlogue
pacman -S gitlogue

With the binary on your PATH, run it inside a repository with no arguments to start the screensaver, which the README says plays random commits endlessly. To watch something specific, pass a commit or a range.

gitlogue
gitlogue --commit abc123
gitlogue --commit HEAD~5..HEAD
gitlogue --order asc --loop

Expect a full-screen terminal UI, not printed output. Space toggles play and pause, h and l step one line, H and L step one change, p and n move between commits, and q or Ctrl+c quits. The menu opens with Esc. If you want to see uncommitted work instead of history, gitlogue diff shows staged changes and gitlogue diff --unstaged shows unstaged ones.

The screensaver claim comes with two warnings

The README's most useful passage is the warning block above the quick start, because it contradicts the feature list. gitlogue advertises a screensaver mode, then states plainly that it is "not a true screensaver": there is no power management and no screen blanking. It is a visual display, nothing more. Anyone expecting the terminal to blank after an idle period will be disappointed, and the naming invites that expectation.

The second warning concerns OLED displays. Static elements such as the editor background and border lines may cause burn-in over extended periods, while LCD displays are described as generally safe. That is a real constraint for the ambient-display use case, which is exactly the scenario where the tool would run for hours. If your monitor is OLED, the feature that makes gitlogue attractive is the feature that puts it at risk.

A third limit is implicit in the language list. Highlighting depends on bundled tree-sitter grammars, so a file type outside the 32 named languages will not be highlighted the way the README's screenshots suggest. The list is long, but it is a list, and it stops.

Gource shows the repository; gitlogue shows the file

The obvious comparison is Gource, which appears in the related searches around this project. The difference is the level of abstraction. Gource visualizes a repository as a growing tree of files with contributors moving through it, which is a way of seeing project shape and activity over time. gitlogue stays inside the editor view: a file tree, a code pane, and characters appearing one at a time. Gource answers "what did this project look like as it grew"; gitlogue answers "what did this particular change look like when it landed."

That makes them complements rather than substitutes. If your goal is a video showing a year of activity, Gource is built for that and gitlogue is not. If your goal is a close reading of a single commit or a short range during a talk, gitlogue's editor-level detail is the thing Gource does not attempt. The related searches also mention Agentmux and Neo, but neither is described anywhere in the repository documentation, so no comparison can be made here.

Within the same author's work, GitType is a different tool again: a CLI typing game built from source code. gitlogue replays history; GitType turns code into an exercise.

Configuration, themes and what to verify

gitlogue reads ~/.config/gitlogue/config.toml. The README says the file covers the default theme, typing speed and background preferences, and points to docs/configuration.md for the full set of options. The repository also ships a docs/themes.md for customization and nine built-in themes, which you can list and select from the command line rather than editing TOML by hand.

gitlogue theme list
gitlogue theme set dracula
gitlogue --theme dracula --speed 20

Before adopting it, verify two things the README does not settle. First, the configuration guide is the only authority on which keys exist in config.toml; the README names three categories and stops. Second, the repository's docs directory is where installation troubleshooting lives, and the README's install section defers to it for "more options and troubleshooting". Neither document is reproduced here, so treat the README's flag list as the confirmed surface and the config file as documented elsewhere.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-09-09, and the repository is not archived. Releases are frequent: v0.11.0 on 2026-08-30, v0.10.0 on 2026-07-25, v0.9.0 on 2026-04-20. The project is still on a 0.x version, which in Cargo terms means the maintainer reserves the right to break things between minor releases. Cargo.toml pins the package at version 0.11.0, so an upgrade from 0.10 to 0.11 is a minor bump by semver but not a compatibility promise.

That matters for the dependency surface. gitlogue links a large set of tree-sitter grammars, each versioned independently, plus git2 with vendored OpenSSL and libgit2. Vendoring means the build does not depend on system libraries, which helps reproducibility, but it also means a fresh cargo install compiles those vendored components. The README lists no minimum Rust toolchain version.

The licence is ISC, a permissive licence that imposes few obligations beyond retaining the copyright notice. The repository also carries a LICENSE-THIRD-PARTY file, which is what you would expect given the number of bundled grammars. If you redistribute a binary, that file is the one to read. This is a description of the repository contents, not legal advice.

Editorial conclusion

Adopt gitlogue if you present code history live, record terminal demos, or want an ambient display that happens to be your own repository. Skip it if you need searchable logs, blame, or anything scriptable: gitlogue renders commits, it does not answer questions about them. Before you rely on it, check the two documented constraints yourself: run gitlogue diff --unstaged on a repository with pending edits to confirm the working tree view, and read docs/configuration.md for the keys available in ~/.config/gitlogue/config.toml. On OLED panels, weigh the README's burn-in warning against leaving it running all day.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. README
4. Releases
5. unhappychoice/gitlogue on GitHub