git-split-diffs renders GitHub style side by side diffs in your pager

Installing as a global git pager

The installation is a global npm install followed by one git config line that points core.pager at the tool and pipes its output through less:

npm install -g git-split-diffs

git config --global core.pager "git-split-diffs --color | less -RFX"

The `--color` flag is what makes it emit ANSI colour rather than plain text, and the `less` flags matter. `R` keeps raw control characters so colours survive, `F` quits if the content fits on one screen, and `X` stops less from clearing the screen on exit, which is what preserves the diff when you scroll.

If you would rather keep the dependency inside a project, the local form uses npx instead:

npm install git-split-diffs

git config core.pager "npx git-split-diffs --color | less -RFX"

The difference is scope. The global config applies to every repository you open, while the local one applies only in the repository where you set it and relies on npx resolving the package. Both appear in the README as first class options, which suggests the author expects both audiences.

There is also a manual path for piping anything through it, useful the first time you want to see what you are committing before you commit it:

git diff | git-split-diffs --color | less -RFX

The README states this requires Node 14 or newer, and the package metadata in the repository asks for something stricter: the engines field declares Node 18 or later, and the pinned type definitions target Node 18. Both statements are about the same runtime. Treat 18 as the real floor and check your version before the install fails.

The narrow terminal fallback is the most thoughtful part

A split diff needs horizontal room, and git-split-diffs handles that case instead of pretending it does not exist. It measures the terminal and, if two lines of `min-line-width` cannot fit on screen, it reverts to a unified diff. That value defaults to `80`, which means any terminal narrower than 160 characters gets unified output.

You can change the threshold, and the README gives the extremes explicitly. Setting `min-line-width` to `0` forces split output always, regardless of how cramped the window is.

git config split-diffs.min-line-width 40

The troubleshooting section points back at this feature for the most common complaint, that diffs are not appearing side by side. That is a sign the author considered it the first thing a new user would hit, and it is also the fastest thing to check when a colleague says the tool is not working for them.

The same honesty shows up in the scrolling note. To enable scrolling in the terminal instead of wrapping, the pager invocation changes by adding a plus sign to the less flags, turning `-RFX` into `-+LFX`. The README explicitly flags the difference from the main configuration because it is a single character that is easy to miss.

Syntax highlighting through Shiki, at a measurable cost

Highlighting comes from Shiki, which uses the same grammars and themes as VS Code, and the `diff-so-fancy` acknowledgement explains why: that tool showed what was possible for terminal diff colouring. Chalk handles the terminal styling layer and supports several colour levels.

The theme is a git config value, and an empty value disables highlighting entirely:

git config split-diffs.syntax-highlighting-theme ''

The README also publishes a performance table for piping the output of `git log -p` through the tool with the default theme, measured per thousand lines. With everything enabled it reports 45 ms/kloc, without syntax highlighting 15, and without either syntax or inline change highlighting 13. Read that as a design trade-off rather than a benchmark to quote: highlighting is the expensive part, and it costs roughly three times the rest of the rendering.

That ratio is why the two adjacent settings exist. Lines wrap to fit the screen by default and can be truncated instead with `wrap-lines`. Salient changes within a line are highlighted by default and can be turned off with `highlight-line-changes`. Both are separate switches so you can keep the highlighting you care about and drop the part you find noisy or slow.

Nine bundled themes, and a way to write your own

Themes are switched with the `theme-name` config key, and there are nine shipped: arctic, dark (the default), light, github-dark-dim, github-light, solarized-dark, solarized-light, monochrome-dark and monochrome-light. The GitHub pair is the obvious choice for anyone who spends the day reading pull requests, and the monochrome pair is the one to try if colour is distracting rather than helpful.

Writing your own is a two-step process. Set a theme directory, set a theme name, and the tool loads `name.json` from that directory:

git config split-diffs.theme-directory </path/to/theme>
git config split-diffs.theme-name <name>

The README suggests starting from one of the existing definitions in the repository's themes directory. If you want background colours gone from a built-in theme instead of writing a new one, the documented route is the custom theme documentation, and removing `backgroundColor` should usually do it.

Because the package publishes `themes/*.json` as part of its npm files alongside the built bundle, custom themes are a supported path rather than a hack, and the theme JSON files are in the repository if you want to see what a definition actually looks like.

Where it sits against delta and diff-so-fancy

The README names its own competition, which is unusual and useful. It credits diff-so-fancy for showing what was possible and shiki and chalk for the highlighting and styling layers. Then it points at delta, which approaches the same problem in Rust.

That last line is the real comparison to make. delta is a Rust binary, so its startup time and streaming behaviour are in a different class from a Node tool, and it has become the common recommendation for anyone who wants a nicer diff pager. git-split-diffs is a Node program whose distinguishing feature is the GitHub style two column layout plus VS Code syntax highlighting and a themable JSON format.

So the honest framing is: if you want the fastest pager with good defaults, that is the Rust option. If you specifically want split output, Shiki's VS Code quality highlighting and editable themes, and you already have Node in your workflow, this is the tool for it.

The build setup reflects a small TypeScript project rather than a monolith. It is ESM with an esbuild step, a `bin` entry pointing at `build/index.mjs`, and scripts for linting, building, a dev watch mode, a production build, tests through Jest with experimental VM modules enabled, a theme preview server, and a benchmark. `prepublishOnly` runs lint, the production build and tests before publishing, which is the sort of discipline that explains why the releases are uneventful.

Sparse release history and a release that is mostly a dependency bump

Three releases are published and they are far apart. v2.1.0 on 2024-07-05 lists nothing but a changelog link. v2.2.0 on 2024-09-21 added support for loading custom themes. v2.3.0 on 2025-10-23 bumped esbuild from 0.17.19 to 0.25.0 and tried a tentative fix for issue 16.

That pattern says the feature set is settled and the remaining work is maintenance. A project whose last published release was a dependency bump and a tentative fix is one where you are unlikely to find a missing feature, and where the risk is instead that a future Node release or a terminal quirk needs attention.

The repository is not archived and the last push was on 2026-09-13, so work is still happening even though the release page has been quiet since October 2025. If you are the kind of user who wants a pager that ships regularly, that gap between pushes and releases is worth watching. If you want a pager that already does one specific thing well, it does.

The tree also has a `todo.md`, a `.node-version` file pinning the development Node version, an ESLint flat config, a Jest config and a Prettier config. Small project, conventional layout, MIT licensed.

Editorial conclusion

git-split-diffs is a good fit if you read diffs on a wide monitor and want the two-column layout you know from GitHub, and if you want to restyle it yourself rather than accept a fixed colour scheme. It is the wrong tool on a narrow terminal, where it deliberately falls back to unified output, and the wrong choice if you want fuzzy search inside your pager, since the documented configuration pipes into less and nothing here describes find or filter behaviour. Two things to verify before adopting it. The README says Node 14 or newer while the package engines field requires Node 18, so check what your environment actually has. And if you want scrolling rather than wrapping, the pager flag changes by adding a plus sign to the less invocation, which is the easiest setting to get wrong.

Frequently asked questions

Official sources

1. banga/git-split-diffs on GitHub
2. Issues
3. License: MIT
4. README
5. Releases