A performance-focused, magit-inspired git interface for Neovim.
:Gitlad
I've used magit for years and it's genuinely one of the best pieces of software I've ever used. When I moved to Neovim I wanted something as close to the real thing as possible — the keybindings, the transient popups, the staging workflow, all of it.
Neogit is the established option here and for most people it's probably the right choice. It's mature, well-maintained, and has a great community. Cameron and the neogit team have done excellent work and our projects have different goals.
My particular itch was performance and staying as close to magit's UX as possible. gitlad uses optimistic state updates: when you stage a file, we run the git command, check the exit code, and update the UI state directly in Lua — no round-trip to git status. The result is a snappy interface regardless of repo size. Press gr when you want to resync, or enable the optional file watcher for automatic stale detection.
Unstaged, staged, untracked, and conflicted sections. Inline diff expansion with TAB. Hunk-level and visual selection staging.
Magit-style popup menus for commit, push, pull, fetch, branch, log, diff, stash, rebase, cherry-pick, revert, reset, merge, and submodule.
Stage, unstage, and discard operations update UI instantly via a pure Lua reducer — no waiting for git round-trips.
Press $ to see every git command run, its output, exit code, and duration. Full transparency.
Full rebase editor with pick, reword, edit, squash, fixup, drop. Instant fixup/squash with c F / c S.
Full-buffer diffs, side-by-side views, and 3-way merge conflict resolution delegated to diffview.nvim.
Following evil-collection-magit conventions — vim-native movement with magit operations. If you're familiar with magit, you'll feel right at home.
All keybindings are discoverable from within the plugin — press ? in any gitlad buffer to open the help popup showing every available key.
Using lazy.nvim:
-- lua/plugins/gitlad.lua
return {
"actionshrimp/gitlad.nvim",
dependencies = {
-- Fork with 3-way staging (magit/ediff style).
-- The original sindrets/diffview.nvim also works.
{
"actionshrimp/diffview.nvim",
branch = "3-way-staging",
},
},
config = function()
require("gitlad").setup()
end,
}
Then open any git repo and run :Gitlad.
See the README for full configuration options.
Magit is the single best git interface ever created. Jonas Bernoulli has spent over a decade building and maintaining it, and everything about gitlad — the keybindings, the popup system, the staging workflow, the entire UX philosophy — is borrowed directly from his work. This project is a cheap imitation of the real thing, and I mean that sincerely. If you use git, please consider supporting Jonas.
Support magitNeogit is the established magit-for-Neovim and for the majority of people it's probably the better choice. Cameron and the team have built something great, and I'd encourage anyone evaluating options to try neogit first. gitlad exists because I had slightly different design goals around performance and magit fidelity, not because neogit isn't good — it is.
gitlad was written with heavy AI assistance. I'm not going to pretend otherwise — you can look at the PR history and see exactly how it was developed.
That said, I've personally spent a huge amount of time on this over the last month or so. Not just prompting, but designing the architecture, reviewing every PR, writing and iterating on extensive development guidelines, and building a tight feedback loop with comprehensive automated testing. The guardrails I put in place to ensure quality — mandatory tests, atomic commits, CI checks, local reviews — were as much of the work as the code itself.
I think the result speaks for itself, but transparency matters. The code is all there if you want to judge it on its merits.
I've inevitably baked in some of my own workflows and biases. Magit itself is vastly more configurable, and I've very likely overlooked key use cases that matter to you.
If something is missing, broken, or could be better — open an issue. I'm particularly interested in hearing from people whose workflows don't quite fit what's here. The whole point of putting this out there is to learn what I've missed.