difit: a local Git diff viewer with a GitHub-style Files changed view

What difit solves, and who it is for

`git diff` in a terminal is fine for small changes and painful for large ones. You lose the file tree, the side-by-side alignment, and any place to attach a thought to a specific line. difit takes the diff you already have locally and serves it over HTTP as a GitHub-like Files changed view, so the reading experience matches the one most developers already know.

The second half of the pitch is different. difit ships a comment system whose output is a prompt: the README describes a Copy Prompt button per comment and a Copy All Prompt button for the whole set, formatted for AI coding agents. That makes difit less a replacement for a code review platform and more a way to turn your own reading of a diff into instructions an agent can act on. The intended user is a solo developer or a small team working with an agent, reviewing before or after the agent writes code.

How difit turns a diff into a served page

The package is TypeScript with a `bin` entry at `./dist/cli/index.js`, and the published `files` list covers `dist` plus `README.md`. The build is split: `build:cli` compiles the CLI with `tsc --project tsconfig.cli.json`, and the default `build` script then runs `vite build` for the client. So the npm package carries both a Node CLI and a bundled front end, and the CLI is what starts the server that serves that front end.

Input selection is the part worth understanding, because difit has three modes and the rules for picking one are explicit. Positional arguments put it in Git mode: `difit <target>` shows a single commit, and `difit <target> [compare-with]` compares two revisions. `--pr` puts it in PR mode and, per the README, fetches patches by running `gh pr diff --patch` under the hood. Stdin is the third mode, and the README states the precedence clearly: `-` explicitly enables stdin mode, positional arguments or `--pr` force Git or PR mode and suppress stdin, and auto detection applies only when no explicit mode is selected and stdin is a pipe, file or socket.

That ordering matters in practice. `git diff --cached | difit` works by auto detection, but the README also shows `git diff --cached | difit -` as the explicit form. If you pipe a patch and also pass a revision, the revision wins and your pipe is ignored.

Installing difit and reviewing your first commit

The README offers a no-install path first. Running it through npx starts a server and opens the viewer for the latest commit:

npx difit  # View the latest commit diff in WebUI

For repeated use, the global install is the documented route:

npm install -g difit
difit  # View the latest commit diff in WebUI

The README does not describe a Windows-specific installation path beyond npm, and it does not document an uninstall step. The homepage listed in `package.json` points at the GitHub repository, while the repository metadata gives a GitHub Pages site for the project.

Once installed, the working-tree case is the one most people reach for. The README lists three special arguments for uncommitted work:

difit .        # All uncommitted changes (staging area + unstaged)
difit staged   # Staging area changes
difit working  # Unstaged changes only

By default the server binds `127.0.0.1` on port `4966`, and the README states the port falls back to the next one if it is occupied. If you want to reach the viewer from another machine, `--host 0.0.0.0` is the documented flag, and `--no-open` stops the browser from launching on its own. Two flags change the lifetime of the process: `--keep-alive` keeps the server up after the browser disconnects, and `--background` keeps it running and prints JSON connection info instead.

Comments, prompts and where they are stored

The comment workflow is the reason to prefer difit over a plain diff pager. You click the comment button on a diff line or drag to select a range, edit comments later with the edit button, and then copy either a single comment or the full set in a structured format aimed at an agent. The README describes the storage as browser localStorage, scoped per commit.

That scoping is a real constraint, not a footnote. Comments belong to a commit in a particular browser profile. Clear site data, switch to another browser, or move to a different machine, and the comments are gone. There is no documented export, no server-side persistence and no sync. The `--clean` flag clears all existing comments and viewed-file state on startup, which is useful when a commit has been amended and the old positions no longer mean anything.

For scripted or agent-driven flows, `--comment` injects comments at launch. It is repeatable and accepts a JSON object or a JSON array, with two supported types: `thread` creates a new thread at a given diff position, and `reply` adds a reply to the latest existing thread at that position. The README notes that difit skips importing a comment if an identical one already exists, which makes repeated launches idempotent rather than duplicating threads.

GitHub PR mode and its dependency on the gh CLI

`difit --pr https://github.com/owner/repo/pull/123` pulls a PR's patches in and renders them locally. The README is direct about the mechanism: it runs `gh pr diff --patch` under the hood, so GitHub CLI is not optional in this mode. Authentication follows the same route. The recommended setup is a one-time `gh auth login`; for CI or non-interactive use, set `GH_TOKEN` or `GITHUB_TOKEN`. GitHub Enterprise Server is supported by authenticating `gh` against your host with `gh auth login --hostname YOUR-ENTERPRISE-SERVER`, or by setting `GH_HOST` alongside a token.

One capability is unique to this mode. According to the README, difit imports unresolved inline review threads from the PR and shows them as startup comments in the viewer. That is genuinely useful when you want the review context next to the code without opening a browser tab on github.com.

The limitation runs the other way. difit reads those threads; the README does not describe posting a comment back to the PR. Your local comments stay local. If your workflow depends on review feedback landing on the pull request, difit is the wrong tool for that step.

Feeding difit patches from other tools

Stdin mode is the escape hatch that makes difit useful beyond Git. Any unified diff can be piped in, and the README gives several concrete examples: comparing two files with `diff -u`, reviewing a saved patch with `cat changes.patch | difit`, comparing against a merge base with `git diff --merge-base main feature | difit`, and reviewing an entire existing file as newly added with `git diff -- /dev/null path/to/file`.

The merge-base example is worth noting because it overlaps with a flag. `--merge-base` resolves the base revision with `git merge-base` before diffing, and the README restricts it to Git revision mode. If you are already computing the merge base in the shell and piping the result, you do not need the flag.

The `--context` flag also comes with a boundary: it limits surrounding context lines per change, with `0` showing changes only, and the README states it is not available with `--pr` or stdin. So the two modes where you are most likely to receive a diff you did not generate are exactly the two where you cannot trim context. That is a design trade-off, not a bug, but it is worth knowing before you plan a workflow around it.

Where difit stops being the right choice

difit assumes a local repository and a browser on the same machine. The default bind address is `127.0.0.1`, and reaching it from elsewhere requires `--host 0.0.0.0`, which the README presents as a flag rather than a supported deployment. There is no documented authentication on the server. Anyone who can reach the port can read the diff and the comments it contains.

A second boundary is collaboration. Review comments live in localStorage per commit, so two people reviewing the same commit in two browsers have two separate comment sets. Nothing in the README describes sharing, exporting or merging them. If your review process needs multiple reviewers on one artifact, difit does not provide that layer.

A third is CI. `--background` prints JSON connection info and `--keep-alive` keeps the process alive, which suggests headless or long-running use, but the README does not document a CI recipe, and PR mode still depends on a `gh` binary and credentials. Treat difit as a developer-local tool until you have verified otherwise.

Alternatives and the difference in approach

The closest comparison in the same space is a TUI diff viewer such as delta, which formats `git diff` output for the terminal. The difference is structural rather than cosmetic: delta changes how text is rendered in your shell, while difit starts an HTTP server and serves a React front end with a file list and per-line comment controls. If your review happens entirely in a terminal and you never need to attach a comment to a line, delta is lighter, has no port, and has no browser dependency.

Editor-integrated review is the other alternative. Editors that render diffs and support inline comments keep you in one window and usually persist comments with the repository rather than in browser storage. difit's advantage is that it is editor-agnostic and its comment output is formatted as an agent prompt, which is the specific thing the README leads with. The trade-off is that you leave your editor, and your comments live somewhere your editor cannot see.

Maintenance, versioning and licence

The repository is not archived, and the last push was on 2026-08-28, the same day as the v5.0.12 release. The release cadence visible in the notes is tight: v5.0.10 and v5.0.11 landed on 2026-08-08 and 2026-08-09, then v5.0.12 on 2026-08-28. Version numbers are at 5.x, and the CLI is published to npm as `difit`.

Upgrade cost is low by construction. `npx difit` always resolves the current published version, and a global install upgrades with a normal npm command. The thing to watch on upgrade is not the CLI but your stored state: comments and viewed-file markers are keyed per commit in localStorage, and the README documents `--clean` as the way to reset them. If a new version changes how positions are computed, `--clean` is the documented escape.

The licence is MIT, stated in `package.json` and present as a `LICENSE` file at the repository root. That permits commercial and private use with attribution requirements typical of MIT. This is a description of the licence text, not legal advice; read the file if the distinction matters to your organisation.

Editorial conclusion

difit fits developers who review their own commits, working-tree changes or a GitHub PR and want a GitHub-shaped view plus comment prompts they can paste into an AI agent. Skip it if you need inline comments posted back to GitHub, or if you only ever read diffs inside your editor. Before adopting it, check that `gh` is authenticated for `--pr` mode, confirm which port 4966 falls back to on your machine, and remember that comments live in browser localStorage per commit, so switching browsers or clearing storage loses them.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yoshiko-pg/difit on GitHub