vim-signify: VCS diff signs in Vim's sign column

What vim-signify solves, and for whom

The sign column is the narrow strip Vim reserves to the left of the line numbers. Signify fills it with markers for lines that a version control system reports as added, modified or removed. The README states the plugin uses the sign column to indicate added, modified and removed lines in a file that is managed by a version control system. That is the whole product: a persistent, per-line view of your working copy against the repository, visible while you edit rather than after you run a diff command.

The audience is broader than the git-only crowd. The README lists git, mercurial, darcs, bazaar, subversion, cvs, rcs, fossil, accurev, perforce, tfs, yadm and jj as supported systems. If your workplace keeps a perforce or subversion checkout and your personal projects live in git, one plugin covers both. The README also states it handles nested repositories controlled by different VCS, which matters when a vendored subdirectory is its own git repository inside a mercurial parent, for example.

Beyond the signs, the plugin ships mappings for navigating hunks, described in the README as blocks of changed lines, and an operator that acts on hunks. Those two features are what separate it from a pure indicator: you can jump between change regions and apply an operation across one without reaching for a terminal.

How the sign column gets populated

The plugin shells out to the VCS tool and parses the result into sign placements. The README states that execution of VCS tools is asynchronous for Vim 8.0.902+ and Neovim, which is why the master branch carries that version floor. On older Vim the same work has to happen synchronously, and the README points those users at the legacy tag instead.

Because the plugin runs external commands rather than reading a diff format directly, the supported-VCS list is really a list of command integrations. That has a practical consequence the README implies but does not spell out: if your VCS binary is not on the path Vim sees, or the repository layout confuses the tool, there is nothing for the plugin to parse and the sign column stays empty. There is no bundled fallback diff engine.

Two design choices stand out. First, the README states the plugin preserves signs from other plugins, which matters because the sign column is a shared resource and a plugin that clears it wholesale will fight with linters, breakpoint markers or debugger indicators. Second, it offers an alternative workflow: disable the plugin by default and toggle it per buffer on demand. That inverts the usual model where every buffer pays the cost of a VCS query. Optional line highlighting, optional skipping of filetypes or filenames, and optional stats in the statusline round out the configuration surface.

Installing vim-signify and seeing your first signs

The README gives a version-conditional snippet for vim-plug that picks the legacy tag when the running Vim is too old. Copy it as-is; the patch check is what decides which branch you get.

if has('nvim') || has('patch-8.0.902')
  Plug 'mhinz/vim-signify'
else
  Plug 'mhinz/vim-signify', { 'tag': 'legacy' }
endif

After running :PlugInstall, the README recommends one setting for the async path. The default updatetime of 4000ms is too slow for the sign column to feel current, so the README suggests lowering it.

" default updatetime 4000ms is not good for async update
set updatetime=100

With that in place, open a file inside a repository and edit a line. The sign column should show a marker for the modified line within roughly the updatetime window. If nothing appears, the first thing to check is whether the VCS command for your repository works from a terminal in that directory, since the plugin depends on it. The README does not document a diagnostic command for this, so a shell check is the practical route.

Where vim-signify is the wrong tool

The clearest boundary is the version floor. The master branch is async-only and requires at least Vim 8.0.902. If you are on an older Vim and cannot or will not install the legacy tag, this plugin is not for you. The README presents the legacy tag as the answer rather than claiming the async path degrades gracefully, and there are no recent releases listed for the repository, so the legacy line is a maintenance branch rather than a parallel product.

A second boundary is scope. Signify shows you changes; it does not stage, commit, resolve or rewrite them. If your workflow needs interactive staging, conflict resolution or history rewriting from inside the editor, the sign column is a display layer and nothing more. The hunk operator acts on hunks in the buffer, not on the index.

A third case is the sign column itself. The README states the plugin preserves signs from other plugins, but that only helps if the other plugin is well behaved. If you already run a debugger, a linter or a test-status plugin that owns the sign column and clears it on every update, you will get flicker or lost markers, and the fix belongs in the other plugin. Finally, the plugin runs VCS commands over your working tree. In a very large repository, or on a network filesystem where the VCS binary is slow to start, the async execution keeps the editor responsive but the signs will lag, and no configuration in the README changes that.

vim-signify against vim-gitgutter

The README itself names vim-gitgutter as the similar plugin for git. The difference in approach is the VCS surface. vim-gitgutter is a git plugin: its whole model assumes git as the backend. Signify treats git as one of thirteen supported systems and adds a layer that detects which VCS manages a given file, including the nested-repository case the README calls out.

That generality costs something. A git-only plugin can lean on git-specific plumbing and git-specific concepts without a translation layer, while Signify has to normalize whatever each tool prints into the same three sign categories. When a VCS reports a change in a way that does not map cleanly onto added, modified and removed, the sign column has to round it to one of those, and the README does not describe how each backend handles that.

The second difference is the surrounding feature set. Signify bundles hunk navigation mappings, a hunk operator, a popup preview of the change on the current line, a diff-mode view of all changes, optional line highlighting, optional stats in the statusline, and the toggle-per-buffer workflow. If you already run vim-gitgutter and it does what you need, the migration is not obviously worth it unless one of those extras, or the multi-VCS support, is the thing you are missing.

Maintenance, licence and upgrade cost

The repository is not archived. The last push was on 2026-03-12, which is recent enough that the project is not dormant. There are no recent releases listed, so there is no version number to pin to beyond the branch and the legacy tag named in the README.

The practical upgrade cost is low because the plugin is Vim script with no build step. Installing means cloning or letting a plugin manager fetch it; there is no compilation, no runtime dependency to install and no service to run. The one upgrade hazard is the version floor: a Vim downgrade, or moving to a machine with an older Vim, silently changes which branch you should be on, and the README's conditional snippet exists precisely to handle that.

The licence is MIT, stated in the repository metadata and in the LICENSE file at the top level. MIT is permissive: it allows use, modification and redistribution with the licence text retained. That is a statement about the licence terms, not legal advice; if you are bundling the plugin into a distribution or a commercial product, read the LICENSE file and the notices of any other plugins you ship alongside it.

Editorial conclusion

Adopt vim-signify if you work in Vim or Neovim 8.0.902 or newer, edit files under git, mercurial, subversion, perforce or any of the other supported systems, and want hunk navigation without leaving the editor. Skip it if your Vim predates 8.0.902 and you refuse the legacy tag, or if your only VCS is git and you already have vim-gitgutter configured the way you like. Before installing, confirm your Vim version with :version, check that the sign column is not already claimed by another plugin that does not preserve signs, and set updatetime to a small value, since the README notes that the default 4000ms is not good for async update.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mhinz/vim-signify on GitHub
4. README