GitGutter's five gutter marks and the two write actions in its diff popup

The README defers four topics to a docs site built from the same tree

The GitGutter README is short and spends its closing section on four links: installation, usage, settings and troubleshooting, each a separate page under https://jisaacks.github.io/GitGutter/. Nothing in the file says how to obtain the plug-in, which channel to add it from, or which Sublime Text builds it supports. The rest of the repository partly fills that hole on its own, because `mkdocs.yml` and `docs/` sit at the root and the five gutter images the README links to are stored under `docs/assets/images/`. The documentation site is therefore generated from the same checkout, so those four pages can be read against the code in one place.

What the README never mentions is defaults. Not one setting name appears anywhere in it. The only configuration file a reader learns about by inference is `GitGutter.sublime-settings`, named in the file list rather than explained, which means an install decision has to be made from the shape of the tree instead of from the prose.

Three keymaps, one per platform, and no documented binding for any command

The root directory is laid out as a Sublime Text plug-in, and the layout is per platform. There are three keybinding files, `Default (Linux).sublime-keymap`, `Default (OSX).sublime-keymap` and `Default (Windows).sublime-keymap`, so bindings are maintained three times rather than shared once. Commands are split in a similar way: `Default.sublime-commands` holds what a user triggers, while `release.sublime-commands` sits beside `release.py`, the file that gives the plug-in a release path. `Main.sublime-menu` supplies the menu entries.

The README names three of those commands in prose, Goto Change, Copy from Commit and Revert to Commit, but shows no key combination for any of them and does not say which keymap file holds them. A user who wants to rebind Goto Change has to open the keymaps or follow the README's settings link, and the repository makes no promise that the three names in the README are the complete command set.

Deletions are marked as region borders because the line is gone

The gutter column carries five marks, and they are not all the same kind of thing. Three describe a single line: inserted, modified, and deleted. The deleted entry is worded as borders on a region rather than as an icon of its own, which matches the case it has to cover: a deleted line has no line left in the buffer, so the only place a mark can go is the seam above and below the gap. The other two, ignored and untracked, describe a whole file instead.

One column is therefore mixing per line and per file states, and the list gives no rule for what a file level mark looks like when more than one state applies. The glyphs are attributed to the default theme, so the marks come from whichever theme is active rather than from drawing code inside the plug-in.

The diff popup toolbar puts two write actions next to navigation

Opening a modified line brings up a diff popup whose toolbar mixes three kinds of control. Navigation comes first: close, go to the first change, go to the previous change, go to the next change. A toggle then switches difference highlighting on and off, which decides whether the popup shows the differences between the commit and the working content or the original content from the commit.

The last two controls are write actions rather than views: copy the original content from the commit, and revert a modified hunk to the original state in a commit. Both reach into the buffer in front of you. The README does not name the commit either one works from, and does not say whether a reverted hunk ends up staged, committed, or sitting in the working tree, which is the first thing to establish before trusting the revert.

Gutter icons follow the theme, the popup keeps its own stylesheet

Both surfaces the plug-in draws are styled from files in the package root, and the icon set is not one of them. The five gutter marks are described as belonging to the default theme, and a `themes/` directory sits next to `gitgutter_popup.css`, the stylesheet for the popup. Marks follow the editor's color scheme while the popup keeps styling of its own.

That split is worth knowing before anything goes wrong. Switching schemes is the first thing to try when marks vanish or turn hard to see, and the README carries no note about that failure mode. A user who wants to recolor the popup edits a CSS file inside the package; a user who wants different gutter marks changes the theme. Those are two files for two surfaces, and only the second one is a setting.

A Python package layout wrapped around the editor files

Above the plug-in files sits an ordinary Python project: `plugin.py` at the root, a `modules/` package, a `tests/` directory, `setup.cfg`, a `.python-version` pin, a lowercase `makefile`, and `dependencies.json` for the packages the plug-in expects. That combination matters when reading the source, because the behaviour described in the README is code with tests and a build recipe behind it rather than one entry point.

Two more root files are easy to overlook. `messages.json` and the `messages/` directory hold per release notes, the changelog a Sublime Text package ships. `Preferences.sublime-settings` and `Preferences.sublime-settings-hints` are the same settings file in two forms, the second carrying hints, so a preference nobody has set yet can be surfaced in the editor instead of passing silently.

The three newest tags span two years and skip a patch number

The release record moves slower than the file list suggests. Tag `1.11.12` was published on 8 December 2023, `1.11.14` on 2 October 2025, and `1.11.15` on 21 March 2026, so those three span about two years and three months, and the patch numbers between them are not consecutive. The most recent commit carries the same timestamp as `1.11.15`, which makes that tag the current state of the code rather than one left behind by later work.

Eleven issues are open, with 3877 stars and 229 forks recorded against the project. Nothing published states a support window for Sublime Text versions, and the README does not say what should happen when an editor build changes the keymap or menu format.

Editorial conclusion

GitGutter earns a place in a Sublime Text setup and nothing outside one, and the honest test is whether you edit in that editor rather than in anything else the description names. Before installing, check two things the README leaves open: which commit Revert to Commit works from, and whether your color scheme keeps the five gutter marks visible. Reading the plug-in means reading `GitGutter.sublime-settings`, the three platform keymaps and `modules/`, because the settings page on the docs site is where the defaults actually live.

Frequently asked questions

Official sources

1. Issues
2. jisaacks/GitGutter on GitHub
3. License: MIT
4. README
5. Releases