GitCat did not start as a product. It started as an attempt to replace Git Extensions in one demanding workflow during my internship, then ended up on most of my team's laptops without me really planning it.
The repository we worked in was huge, with a pile of submodules and a branch structure nobody could hold in their head. Git Extensions gave us the workflows we needed, but switching repositories or branches meant reloading history, watching memory climb, and waiting on work laptops that had little memory to spare.
So I built something narrow and called it Cherry-Pick Helper. Colleagues tried it, sent me bugs, then asked for the next workflow and the one after that. I kept saying yes. Somewhere along the way it picked up an anime-flavored personality and a cat named Tama, whose job is keeping your repository safe.
The cat caught on faster than the features did.
What it became is GitCat: a performance-focused Git Extensions alternative for large, branch-heavy repositories, built around two constraints:
- Opening, scrolling, and switching should stay responsive as history grows.
- Every operation that touches history should be reversible.
Version 1.0 is now available for macOS, Windows, and Linux. It is open source under GPL-3.0-or-later and built with Tauri 2, Rust, and Svelte 5.
Performance first: keeping a 150k-commit graph responsive
A commit graph is useful only if it remains readable and interactive on repositories with deep, branch-heavy histories. For GitCat, performance is not a benchmark screen or a loading spinner—it determines the architecture.
GitCat uses git2 for reads and a hand-tuned Rust swimlane layout. Results are streamed to a virtualized canvas, so the newest commits appear quickly instead of waiting for the full history to finish.
The rendering pipeline separates four kinds of work:
-
git2walks repository history. - Rust computes the graph's swimlanes.
- Results stream to the frontend as they become available.
- A virtualized canvas paints the visible region instead of creating a DOM node for every commit.
For scrolling, the renderer uses a scroll-blit path: it copies the existing frame and redraws only the newly exposed strip. That keeps text readable and scrolling smooth in a 150k-commit test repository without placing a hard cap on history depth.
Initial load is only half of the problem. Everyday changes such as checkout, branch or tag updates, and staging update the graph incrementally instead of walking the entire history again. Switching context should feel like continuing work, not reopening the repository.
The interesting lesson for me was that “fast Git” and “fast rendering” are separate problems. Optimizing repository traversal is not enough if layout and paint still scale with every commit on every interaction.
That is the replacement target: keep the branch, submodule, staging, history, and recovery workflows that made Git Extensions useful to us, but make large repositories feel immediate on ordinary work hardware.
Reversibility is a product feature
Before GitCat performs a mutation, its Safety Manager pins a snapshot of the repository. That gives the app a global Undo shortcut (⌘Z), and the undo action is itself undoable.
This is more than putting a confirmation dialog in front of a dangerous button. Confirmations help before an operation; snapshots help after you realize the operation was technically valid but not what you intended.
The safety model also shapes the rest of the UI:
- checkout conflicts offer recoverable stash-based paths before a force-discard option;
- force push and other irreversible actions use an explicit danger-confirm flow;
- reflog rescue can restore an earlier
HEADposition; - dangling objects found through
git fsckcan be recovered onto a new branch without moving the current branch; - the
git-filter-repoworkflow includes a backup-and-restore path.
No GUI can make every Git operation harmless. The goal is to keep the normal path recoverable and make the truly irreversible cases unmistakable.
Real Git workflows, not a simplified model
I did not want safety to mean hiding Git’s useful features. GitCat 1.0 includes:
- line- and hunk-level staging, unstaging, and discard;
- drag-and-drop cherry-pick and merge with a three-way conflict resolver;
- linear and interactive rebase;
- bisect with visual cues for the narrowing range;
- per-file history with rename following;
- author and pickaxe (
-S/-G) search; - submodules, patch export/apply, stashes, rerere, and external diff/merge tools;
- WSL-path support on Windows.
There is also a ⌘K command palette, Vim-style navigation, and a multi-repository dashboard. When the GUI is not the right tool, “Open Terminal” drops you into a real shell at the repository root.
Claude Code was part of the build
Claude Code did a lot of the typing, and GitCat moved much faster because of it. I want to say that plainly because, when I shared the project earlier, the use of AI became a larger part of the discussion than the product itself.
Claude accelerated implementation, but I still chose the workflows and safety boundaries, reviewed the changes, ran the tests, debugged failures, and maintain the released code. Its role here was in the development process; it is not a GitCat feature that users have to enable.
Working this way also hardened something I already believed: Git operations should not become invisible. Regardless of who or what typed the code, I want to know what an operation changed, read back what happened, and get out of it when it goes wrong. That principle is why snapshot-first mutation and recovery are product-level requirements rather than optional polish.
Architecture
The desktop shell is Tauri 2. The Rust core uses git2 for reads and the Git CLI for writes, where the snapshot-first mutation policy is enforced. A typed IPC boundary connects it to a Svelte 5 frontend.
Most features live in focused Svelte islands, while the graph remains a custom canvas renderer. That split lets regular interface components stay declarative without forcing the hottest rendering path through a large DOM tree.
Tama, the cat in the interface, is wired to real application states rather than running as a decorative animation. She reacts to searching, conflicts, rebases, recovery work, success, and danger—and acts as the visible face of the Safety Manager.
One current limitation
The release builds are updater-signed, but the application is not yet code-signed or notarized with platform certificates. macOS Gatekeeper and Windows SmartScreen may therefore show a first-run warning; the install guide documents the exact steps. I would rather make that limitation explicit than hide it behind a download button.
Try it
I would especially value feedback from Git Extensions users and people who work in large repositories. Where does your current client make you wait: initial history load, switching branches, scrolling, staging, or something else?
Top comments (0)