For years I ran VS Code as a git client. Not really an editor — a GitLens host. The branch graph, the heat-mapped blame, the inline lens annotations: that was my git workflow.
Then 2025 happened, and that workflow quietly fell apart. Somewhere in there I realized git tools had been built for the wrong person all along.
GitLens kept me tied to the editor
GitLens is a great extension. Every commit annotated next to the code, a file's history as a heat map, the branch graph on a single screen. I used it for years.
The catch is that GitLens only lives inside the editor. To look at commit history, VS Code has to be open. For a long time that wasn't a cost — I was in the editor all day anyway. I was the one typing the code.
2025: my hands left the keyboard
Then Cursor, Claude Code, and Codex showed up. At first it felt like autocomplete with a longer reach. Then I looked up and the agent was doing the actual editing — writing functions, refactoring across files, even making the commits. I direct, I read, I judge.
The role flipped. I'm not the author of the code anymore so much as its reviewer. I spend more time looking at what the agent just did than with my hands on the keys.
And at that point VS Code started to feel like overhead. The agent runs in a terminal. I had no reason to keep an editor open — except one: GitLens. Booting an entire IDE just to glance at a list of commits suddenly looked absurd.
Git tools are still built for the author
Here is the real problem. Almost every git tool — GitLens, Sourcetree, GitHub Desktop, lazygit, the editor's built-in SCM panel — assumes a person who writes the code by hand.
So they put commit, stage, push, merge, rebase, and cherry-pick front and center. They go deep on blame. They pour effort into conflict-resolution UI. All of it is what an author needs.
But in the agent era my git usage looks different. Most of the time I am just:
- seeing what the agent just committed
- deciding whether it makes sense
- expanding the diff when something looks off
- telling the agent to redo it when it is wrong
Nowhere in that loop do I commit, push, or merge by hand. If git surgery is needed, it is faster to tell the agent in words. Yet the existing tools spend their screen space and their weight on exactly the surgery features I now barely touch.
The tools are not wrong. The user they were designed for is just from an earlier era.
What a git tool for the reviewer looks like
So what should a git tool for the reviewer be? I landed on four things.
1. It should be read-only. A tool whose job is verification should not be able to change state by accident. If there is no commit/push/merge button, there is no button to hit by mistake. Read-only is not a missing feature — it is a design decision.
2. It should be resident, not a window. Reviewing is a short action that happens dozens of times a day. Launching and closing an app each time is friction. Better to sit in the tray, expand on a single click, and get out of the way.
3. It should be done in half a second. "Did the agent just do that right?" is a half-second question. If the tool takes longer than that, people simply skip the check. For a glance, speed is the feature.
4. It should not try to be where you fix things — it should hand off to the agent. When something is wrong, the tool does not need to let you fix it in place. Bundle the commit and the diff into clean context and hand it straight to the agent. The agent is better at the fix.
So I built gitwink
gitwink is those four things, built.
gitwink lives in your system tray. Click it — or hit Ctrl+Shift+G — and a panel expands with the recent commits across all of your local repos on one timeline. Filter by repo, time range, or author; click a commit and the message body and changed-file list expand inline.
For the "wait, did the agent actually do that?" moments, a separate diff window opens a side-by-side view — with before/after preview for image assets.
And the key part: Copy as AI context. One press of c and the commit, the file list, and the diff land on your clipboard as a markdown block. Paste it into Claude or Codex and ask "is this right?". The tool does not take the seat of judgment — it just hands over clean material to judge.
gitwink is not a git client. It cannot commit, push, or merge. It is read-only by design. No telemetry, no phone-home, no network calls — it is a small local app built with Tauri 2 and Rust, and the code is MIT.
Windows and macOS builds are on the latest release. (The artefacts are not code-signed yet, so SmartScreen / Gatekeeper will warn on first launch — the release notes have the bypass steps.)
Wrapping up
As agents started writing the code, a developer's job shifted from authoring to reviewing. But most git tools are still designed for the author. A reviewer needs something that is read-only, resident, fast, and able to hand off to the agent. gitwink is the smallest version of that idea I could build.
Top comments (0)