git-delta: a syntax-highlighting pager for git diffs and grep output

What git-delta solves, and who it is for

Plain `git diff` output is a wall of plus and minus signs. The information is all there, but reading a large change means scanning for the boundaries between hunks and guessing which language a line belongs to. git-delta is a pager that sits between git and your terminal and rewrites that output: it applies bat's syntax-highlighting themes to added and removed lines, infers word-level changes with a Levenshtein edit algorithm, and can split the view side by side with line numbers. The README describes the goal as making diff study "both efficient and enjoyable".

The audience is developers who live in the terminal. If you review commits with `git show`, read `git log -p` on a long history, or inspect `git blame` output, delta changes what you see. It also handles non-git input: the README lists syntax highlighting for grep output from rg, git grep and grep, plus rg --json. The project is written in Rust and licensed MIT.

How delta processes a diff: pager, not diff engine

The mechanism is easier to understand once you accept what delta is not. It does not compute diffs. Git produces the diff, delta receives it on standard input, parses the unified diff format, and re-emits styled text. The README notes it "handles traditional unified diff output in addition to git output", which is why the same binary works on output from other tools.

Integration happens through git's own pager hooks. The README's configuration sets `core.pager` to delta, so every paged git command is piped through it. A separate key, `interactive.diffFilter`, is set to `delta --color-only`, which affects the diff shown during interactive staging. That second setting matters: without it, the coloured diff you see in `git add -p` is not the one delta renders. The `navigate` option adds n and N keybindings to move between file sections in a large diff and between diffs in `log -p` views, which is the feature that most changes how a long review feels.

Under the hood, the Cargo manifest shows the bat crate as a dependency with the minimal-application, paging and regex-onig features, which is where the syntax themes come from, along with syntect for highlighting and git2 for repository access. The themes.gitconfig file at the repository root and the themes directory hold the styling definitions. The ARCHITECTURE.md file at the top level is where the project documents the internal structure; the README itself does not describe the parsing stages in detail.

Installing git-delta and configuring your first diff

The package name and the executable name differ, and this trips people up. The README states plainly that the package "is called git-delta in most package managers, but the executable is just delta". The installation page at dandavison.github.io/delta/installation.html is the canonical source for per-platform commands; the repository does not repeat them in the README.

Once installed, the README gives an equivalent pair of setup routes. The gitconfig form is the one to copy if you keep a dotfiles repository:

[core]
    pager = delta

[interactive]
    diffFilter = delta --color-only

[delta]
    navigate = true  # use n and N to move between diff sections
    dark = true      # or light = true, or omit for auto-detection

[merge]
    conflictStyle = zdiff3

The same result can be written with git config commands, which is useful on a machine where you do not want to edit the file by hand:

git config --global core.pager delta
git config --global interactive.diffFilter 'delta --color-only'
git config --global delta.navigate true
git config --global delta.dark true  # or `delta.light true`, or omit for auto-detection
git config --global merge.conflictStyle zdiff3

After that, run any diff-producing command. `git show` on a recent commit should come back with coloured, syntax-highlighted lines rather than the default green and red. If the output looks unchanged, the pager is not being invoked; check that the command is actually paging. Setting `delta.dark` explicitly avoids relying on background detection, which the README lists as automatic but which depends on the terminal reporting its colours correctly. To see what the theme system offers before committing to one, the README documents `delta --show-syntax-themes --dark` and `delta --show-syntax-themes --light`.

Side-by-side, line numbers and the options that change layout

Most delta options are styling, but three change the reading experience enough to be worth deciding on deliberately. Side-by-side view is enabled with `side-by-side = true` under the `[delta]` section. The README notes that this mode has line numbers activated by default and highlights syntax in both panels, and that long lines wrap automatically rather than being truncated. Line numbers can also be turned on independently with `line-numbers = true`.

The trade-off with side-by-side is horizontal space. A wrapped long line in a narrow terminal is harder to follow than the same line in unified view, because the correspondence between the left and right panels breaks down visually once wrapping starts. The README presents wrapping as a feature and does not discuss this cost. For diffs dominated by long lines, unified view with line numbers is the safer default.

Two other layout features are worth knowing about. The README describes stylable box and line decorations for commit, file and hunk headers, and says style strings (foreground, background, font attributes) are supported for more than 20 stylable elements using the same colour language as git. That is a large configuration surface, and the README points to `delta -h` for short help and `delta --help` for the full manual rather than enumerating every key.

Blame, grep and hyperlinks beyond the diff view

Delta is not limited to diffs. The README lists improved `git blame` display with syntax highlighting, and the `--hyperlinks` option formats commit hashes as terminal hyperlinks to the hosting provider page. The supported providers are named explicitly: GitHub, GitLab, SourceHut and Codeberg. File paths can also be rendered as hyperlinks that open in your operating system. This depends on terminal support for the hyperlink escape sequence, a detail the README does not discuss; on a terminal without it, the option has no visible effect.

Grep output is the other extension. The README says delta syntax-highlights grep output from rg, git grep and grep, and the repository description also lists rg --json. The practical consequence is that you can pipe search results through the same pager and get the same theme, which is convenient if you already have delta in your git config and want consistent colouring elsewhere. It is not a replacement for ripgrep's own output modes; delta renders what it is given.

For users migrating from older tools, the README documents `diff-highlight` and `diff-so-fancy` emulation modes. These exist so that an existing configuration can be pointed at delta without rewriting every style key, which is a pragmatic choice rather than an endorsement of either tool's look.

Where git-delta is the wrong tool

Delta is a pager, so everything it shows has already been computed by something else. If your problem is that git's merge algorithm produces confusing conflicts, delta will not fix it; it will render the conflict markers more legibly. The README's own suggestion here is `merge.conflictStyle = zdiff3`, a git setting, not a delta feature. That distinction matters when evaluating the project: several of the improvements people attribute to delta are actually git configuration that delta's documentation recommends alongside it.

The second limitation is configuration weight. The README says delta "has many features and is very customizable" and then directs readers to two help commands and an online manual instead of listing options. That is honest, but it means a new user cannot judge the full surface from the README alone. The repository carries a manual directory and a themes.gitconfig file, which is where the detail lives.

Third, interactive staging is handled by a separate setting. If you configure only `core.pager` and skip `interactive.diffFilter`, the diff you see while selecting hunks stays in git's default rendering. The README's setup block includes both, which suggests this is a common enough omission to deserve a line in the minimal configuration.

Finally, delta is not useful for anyone who reads diffs in an editor or a web interface. The project's whole value is in the terminal, and the README's screenshots make that scope clear.

Alternatives and how they differ in approach

The README names two alternatives directly by providing emulation modes for them: diff-highlight and diff-so-fancy. Both are also terminal diff renderers, and delta's support for emulating their output means a migration can be incremental rather than a rewrite. The difference in approach is scope. diff-so-fancy is a formatting script that post-processes diff output; delta is a compiled Rust binary that embeds bat's syntax definitions and syntect's highlighting engine, which is why it can highlight source code inside a diff rather than only colouring the plus and minus lines. The Cargo manifest makes that dependency explicit.

The other comparison the README invites is with bat itself. Delta uses bat's themes, so the colour schemes are the same, but bat is a file viewer. Delta reads diff input and understands hunk structure, line numbers and navigation between file sections. If you want syntax-highlighted file reading, bat is the tool; if you want syntax-highlighted differences, delta is.

For teams that want the same rendering in a web UI, neither applies. Delta is a local pager and the README describes no server component or shared configuration mechanism.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-02, which is recent. Releases are frequent enough to suggest a maintained project: 0.19.0, 0.19.1 and 0.19.2 all landed in March 2026, with 0.19.2 dated 2026-03-28. The version in Cargo.toml matches the latest release, 0.19.2.

The licence is MIT, stated in Cargo.toml and present as a LICENSE file at the repository root. That is a permissive licence, but this is not legal advice; check the LICENSE file and your organisation's policy before redistributing a built binary.

Upgrade cost is mostly configuration drift. Delta reads keys from gitconfig, and the README's own example includes a commented alternative for every binary choice (`dark = true` or `light = true`, omit for auto-detection), so a config written for one version has room to keep working. The risk is the opposite direction: the Makefile contains a `test_deprecated_options` end-to-end test, which confirms that options are retired over time. Anyone pinning delta in a system package manager should read release notes before jumping versions rather than assuming old style keys still apply. Building from source is a plain `cargo build --release` per the Makefile, and the project's own test target runs the unit tests plus three end-to-end scripts, including one that compares raw output against git on full repository history.

Editorial conclusion

Adopt git-delta if you read diffs in a terminal all day and want syntax highlighting, side-by-side view and n/N navigation without leaving git. Skip it if you only ever view diffs in a GUI, or if you need a diff engine rather than a pager, since delta renders what git produces and does not compute merges itself. Before configuring it globally, check what `git config --global core.pager` currently returns, because delta replaces the pager for every git command that pages output, not just diff and log.

Frequently asked questions

Official sources

1. dandavison/delta on GitHub
2. License: MIT
3. Project website
4. README
5. Releases