A work-in-progress Magit clone for Neovim | Hacker News Reader

A work-in-progress Magit clone for Neovim

github.com

104 pointsJNRowe77 comments

Very early on in my vim journey, I used to use fugitive[1], which is sort of a lighter equivalent of magit for vim. However, I found that too overkill and unwieldy. I never really found any benefits to forcing myself to stay inside vim to run some git command.

These days, I just use git in a tmux split rather than trying to force vim to show some arbitrary git UI. For a nice interactive git UI, I use tig[1]. Tig is essentially like fugitive/magic insofar as it allows me to interactively view a nice graphical log, stage/commit, traverse a file's historical blame, etc. It's a nicer UI compared to something like `gitk`.

I have these mappings in my `~/.vim/vimrc` for git/tig functionalities:

    nnoremap gb :<C-u>echo system('git rev-parse --abbrev-ref @ <bar> tr -d "\n"')<CR>
    nnoremap gB :<C-u>silent !tig blame <C-r>=shellescape(expand("%"))<CR> +<C-r>=expand(line('.'))<CR><CR>:silent redraw!<CR>
    nnoremap gO :<C-u>silent !tig<CR>:silent redraw!<CR>

[1]: https://github.com/tpope/vim-fugitive

[2]: https://github.com/jonas/tig

Well that's useful.

I've been using `!tig` forever. For some reason it was convenient enough for me to never turn it into a mapping. I feel like `tig` damaged me in the sense that using tig and then pressing `S` is my usual workflow, so I just can't get used to either fugitive or magit.

Thanks for these mappings

Fugitive is really useful for a lot of stuff, though I don't use anywhere near all of its functionality. For example, I never rebase within vim. But blaming and especially staging/committing is a far better experience with fugitive than in plain terminal.

There is interactive blaming, staging and committing with tig too, so give that a try.

That said though, I actually prefer using the shell to stage and commit stuff. I think I'm way faster when I'm on the shell performing those actions than in either tig or fugitive.

Tig looks great but fugitive is in my fingers (been using it for something like 7 or 8 years at this point). I'll still check it out.

Not sure when the last time you used fugitive but there was a major overhaul a couple of years ago. You can expand diffs in the commit window and stage parts of the files.

But obviously, stick with what you're comfortable with!

Also `blame` and `grep`

I mentioned blame! :)

I also make heavy use of :Gedit for easily looking at files on other branches.

Missed that. Never used :Gedit, appears hella convenient

:Gedit master:% is a common one I use to see what the current file looks like on master.

I have started using lazygit in tmux splits or neovim terminals and I love it!

I'm not sure what I did wrong but your mapping didn't work for me on Neovim - it either immediately closed the terminal or didn't know what <bar> means.

Eventually I moved to https://github.com/codeindulgence/vim-tig which does the same via `:Tig` and `:Tig!`.

I added those mappings to achieve something similar:

  nnoremap <leader>gb :Tig! blame<cr>
  nnoremap <leader>g0 :Tig! status<CR>

Thank you for inspiration! Tig FTW!

All the mapping worked fine for me as well in vim, and I found gB to be super useful, earlier I had to go first in tree view and then select the file and then use the blame view.

I don't use neovim so I don't know what the differences are. The commands work fine for me in vim however.

Please check best tig integration for vim. https://github.com/iberianpig/tig-explorer.vim

Although I'm a heavy Emacs user, I never understood why is magit so praised.

IMHO, source control just doesn't belong to IDE. Why learn how to use git with Emacs/magit, vim, IntelliJ IDEA, Eclipse, Visual Studio / Code, ... when you can just master the official command line client and forget about the rest? It's available and usable everywhere, while each of these IDE plugins is different and one need to learn and get used to all of them.

>Although I'm a heavy Emacs user, I never understood why is magit so praised. IMHO, source control just doesn't belong to IDE.

Well, then there are two things you never understood, the second being that source control totally belongs to an IDE :)

>Why learn how to use git with Emacs/magit, vim, IntelliJ IDEA, Eclipse, Visual Studio / Code, ... when you can just master the official command line client and forget about the rest

(1) Because you don't want the mental switch.

(2) Because you get better and more immediate visibility (from changed file markers to inline diff).

(3) Because you can do things faster (e.g. right click a file and chose "show file history" or "compare with version...").

(4) Because you can use the same shortcuts, scripting, and other facilities you use elsewhere in the IDE to work with your SCM

(5) Because it has immensely better discoverability (cli discoverability being usually low, with git flags being much worse than the typical case).

and several more reasons besides...

Not to mention that the very same (non-)argument could be said against running your build from the IDE, for doing debug in the IDE ("just master GDB, etc."), for searching on the IDE ("just use grep"), and so on...

> Why learn how to use git with Emacs/magit, vim, IntelliJ IDEA, Eclipse, Visual Studio / Code, ... when you can just master the official command line client and forget about the rest?

Because there are plenty of operations which are way less convenient through the CLI e.g. selecting rebase ranges, reviewing branches, interactively staging and unstaging, etc… are infinitely more convenient via magit. And git blame on the CLI is so full of drudgery it’s basically useless while intellij’s lets me drill through history extremely quickly and easily.

The CLI requires juggling terminals and / or keeping a bunch of crap in your head or clipboard which richer clients simply do for you.

For me, Magit's killer feature is that it provides something equivalent to "git add --interactive" but with a much nicer UI. If you're interactively adding things to a commit then you are effectively editing a text file, and that's always going to be easier in a proper text editor than on the command line. Magit can show you all of the hunks that can be staged simultaneously, allowing you to choose, split, edit, and delete them with a full contextual overview, rather than sequentially.

If make multiple edits to different files before committing, this can be very useful to ensure that the commit makes sense, doesn't include logically unrelated changes, and so on. Or, if you follow a "commit early, commit often" approach, Magit's interface is also nice for restructuring those commits during a rebase/squash.

Perhaps it helps to think of commits as documents in their own right, as commits are effectively patch files, at which point it makes sense to use an editor to, well, edit them.

I think your argument pretty much boils down to the same as for most GUI vs CLI arguments: parallel vs serial, intuitive vs abstract etc... but it all comes at a cost, less flexibility, less power, more complexity, less combinability (less unixy). Just saying, the argument is the same as for any other GUI version of a particular CLI tool, and so it's inevitable we end up with an opinionated divide, because it's not objectively better in all ways - it depends on your values.

For me the most valued aspect is return on my investment for learning a tool... official git cli porcelain will be around for a _long_ time, it's available almost everywhere, it gives the most power and flexibility, I can combine it with all kinds of things for new problems - Magit (or otherwise) exists in a much narrower context, I know it's probably only a subset of git porcelain to smooth over the staging and committing etc, but I prefer to stay familiar with git cli... Perhaps more critically, I've already mastered 95% of the official git cli porcelain and then some, so I suppose from my perspective my return on investment for using yet another git porcelain feels fairly low, even for the specific case of staging, i've done it so much it's second nature, and I'm generally comfortable with the serial nature of globing files over the CLI.

You're assuming magit is less flexible than the command line porcelain, but it's not materially so afaik. It's pretty complete and claims to be the only actual "porcelain" besides the cli. I've certainly never encountered an operation I couldn't perform in magit.

Edit: the relevant claim from the docs is

> Magit is an interface to the version control system Git, implemented as an Emacs package. Magit aspires to be a complete Git porcelain. While we cannot (yet) claim that Magit wraps and improves upon each and every Git command, it is complete enough to allow even experienced Git users to perform almost all of their daily version control tasks directly from within Emacs. While many fine Git clients exist, only Magit and Git itself deserve to be called porcelains.

I felt exactly like you do for years before I finally learned Magit - as a competent CLI user, most of the Git GUIs I'd poked at were frustratingly limited and seemed worse than pointless for someone who had gotten a handle on the Git CLI.

Once I took a little while to learn Magit, it significantly reduced the number of keystrokes I needed for normal git operations.

It also made rebasing less of a chore in several ways.

It's still a bit of a tossup whether I'll use the terminal UI or Magit for a given operation, depending if I'm already in the terminal, but unlike most GUIs, I've found Magit actually reduced my friction for day-to-day work relative to the Git CLI.

emacs predates git by decades and probably will outlast it. While magit is not emacs it is reasonable to expect that it will be maintained by someone for a long time.

> Why learn how to use git with Emacs/magit, vim, IntelliJ IDEA, Eclipse, Visual Studio / Code, ... when you can just master the official command line client and forget about the rest?

Because it is faster, has great visualization and most importantly magit has great fallbacks. You can still use the command line from magit! Pressing "!!" in a magit-status buffer will get you there, while still showing you all the nice info in the other buffers. I use it for "git submodule update --init --recursive" for example.

I have seen people struggling with git log and understanding which commit is on which branch and all that. Of course you can use something like "git log --decorate --graph --color --oneline --all" or even alias that. In magit I do: "mag-stat" (Emacs completes this to "magit-status") which one does usually anyway, to see where the repository is at and whether there are uncommited changes and so on. When I need the graph, I do: "mag-log" "-" "c" "b". Then I can go to any line in the graph and check it out, because it becomes the default for when I type "mag-check" (completed to magit-checkout) and press RET. On command line I would be copying commit ids and branch names and would remember to use my alias for the long git log command.

Edit: Another great feature is how easy it is to commit only some hunks, instead of everything that has changed. Commiting hunks on command line is tedious afaik. You would have to specify row numbers.

> Commiting hunks on command line is tedious afaik. You would have to specify row numbers.

Not necessarily tedious - you can just use "git add -p" to stage hunks individually.

`git add -p` is nice, but Magit's UI is superior, IMO.

I don't know a way to stage individual lines from a given hunk separately in Git's interactive add, but in Magit's that's easy - just select the line you want and press s.

I've even occasionally staged part of a line via selection, when I've actually had two distinct bugfixes on the same line.

Iirc you can edit the patch in git add -p. So fine editing is possible.

In Magit you can easily select arbitrary regions of code to stage (or chunks as you would via the command line). I haven't seen any git interface that is as intuitive for this task.

Try pressing `S` in `tig`. Works like magit but is much faster(when I say faster I'm also including interface lag). I realize that you won't switch, nor do you need to, but the general things people suggest of why magit is superior exist elsewhere as well.

Thanks for the tip, I haven't tried tig yet. That might actually be useful on remote systems in situations where I don't have access to my personally configured emacs.

Why just not use TRAMP to use your personal emacs to edit files on remote systems?

I actually use the git-gutter.el package alongside magit to do the arbitrary region work, and find it to fill the last gap between magit and the built-in version control commands.

As a side note, I am struggling to be comfortable with the word hunk in this context. I would automatically use the word chunk for this usage need. Magit introduced it to me and I balked at the usage. I looked up the etymology and it seems to be a totally legitimate usage - [0]- but to me the word 'hunk' immediately conjures up - as a heterosexual - attractive, sexually appealing man. [0] https://www.etymonline.com/search?q=hunk

It's convenience and discoverability mainly. Usually a git operation in magit:

* Takes fewer keypresses - it has a very nice nested menu system based on single keypresses, which has been split out as "transient" and adopted by a number of other packages.

* Is easier to discover - I've learned of the existence of many things you can do with git by coming across them in the TUI (which is easier and more contextually relevant at any given time than reading the entire command line documentation)

* Generates less cognitive load - the set of available parameters and their default values is immediately visible, not buried in arcane man pages (which open in a separate web browser on Windows)

* Gives far richer and more interactive feedback - when reading the output of git log, the full contents of each commit is a single keypress away, as is checking out the commit in question; code can be blamed in the editor with syntax highlighting; conflicts can be resolved similarly and opened in ediff with a keypress; files and individual hunks can be staged/unstaged with a single keypress when viewing status, etc, etc.

The convenience and completeness of this has been so great that I've not felt the need to memorise the git CLI beyond the absolute basics. To turn the question around, is there any reason I should? Performance is the biggest bugbear, but hasn't been a dealbreaker for me, despite being on Windows most of the time (I've recently started using lazygit to perform simple operations more quickly, though).

You can still use git cli of course. There are still a lot of things I don't know how to do in Magit (though I'm confident I could if I wanted). Magit for staging, committing, fetching, and pushing though is so easy I don't know why you would want to switch to or open a terminal window and type commands rather than just use hotkeys. Try it!

Magit is actually one of the best pieces of software I've ever used.

> ... when you can just master the official command line client and forget about the rest?

I generally agree, I want the full git interface, which is available everywhere and has no limitations and is not bound to a particular editor.

There is however one area I do find useful to have integrated into an editor, various kinds of code annotations... e.g gitgutter, I use this in vim - these type of features compliment git porcelain rather than replace it. i.e gitgutter is no git diff, but it gives you a good feel for what's been changed before you jump into staging. I've never used magit, I wonder if it has such features? or is it really only a git porcelain shortcut?

> gitgutter is no git diff

FYI in gitgutter you can preview the diff for any change (and also edit the hunk and stage it).

Magit has a blame annotation mode, no gitgutter, although there's an unrelated emacs port of that one.

You mean the git cli often acclaimed for it's poor ergonomics?

In any case, Magit is great for two things: easy to use and learn, and interactive features. If you made two separate changes in a single file, you might want to have them on different commits. Doing that on the CLI is tedious at best.

Magit makes doing things like that trivial, which results in better commit hygiene.

git cli has great ergonomics because almost everything is quite straightforward to do.

git cli is confusing, because commands are not orthogonal and flags often change behavior drastically. "git checkout 1.2-dev" checks a branch out, "git checkout src/AceGraph.cpp" checks a file out (i.e. reverts it to checked in state), "git checkout -b feature1234" creates a new branch. These are all ergonomic (easy to use and remember), but also confusing commands (why does git-checkout do three different things depending on arguments?).

I'm with you. I've tried a number of VCS "clients" and most of them are pretty bad, have poor defaults, encourage poor workflows, don't really understand how git works, and consequentially, frequently break down or run into situations the UI cannot handle.

I always tell people to stick to the offical git tools (git CLI, git-gui, gitk). They upper-case Work. They understand git's model, unlike generic VCS frontends. The GUIs are not the best-looking in the world, but very efficient and fast. Lots stick to IDE integrations and don't then don't know how to help themselves if those break, which they frequently do. "I'll just delete my repository and clone again"...

Asides from actually working, which many of the other tools don't really, git's stuff is available everywhere you have git, and also works the same way everywhere.

Yep, I have this frustration with most Git GUIs too.

I've not found that they apply to Magit.

That may just be that most Magit users are also heavy CLI users, though.

Why in Emacs/vim? Because I am already in there staring at text and it's less of a context switch than switching desktops/windows/tabs.

Why not just use cli? I definitely champion _knowing_ cli git for when you need it, but at some point the standard workflows become tedious with the amount of typing required, even using shorthand.

magit provides some super accessible and efficient workflows when paired with e.g. doom-emacs or similar mnemonic keybinds.

Other have mentioned the equivalent of git add -p and believe me using vim's visual selection instead of manually editing out that one line of the patch is a breeze.

I agree when it comes with cluttered UIs in main editors, but this is different.

Having a keystrokes based git interface can be a breeze. I was using GitSavvy in sublime text and it was just amazing.

You can handle annoying operations in milliseconds when you get used. And never the shell can give you that.

With VS Code I can do edits in the diff view. Very very useful and not possible on the command line.

Also better syntax highlighting.

When just viewing or writing commit messages I agree, but as soon as diffs are involved, an IDE can be very helpful.

In general I agree, but one thing I've never learned is resolving merge conflicts in the CLI. I've always just used IDEA's merge resolution tools. Does CLI git provide any tools to help with merging?

You resolve conflicts by staging the resolution and then continuing (rebase) or committing the result (merge, cherry pick). I generally just use git citool/gui for staging my resolutions, which I make in whatever editor I fancy.

Beyond being able to open merge tools? No.

The killer feature for me on IntelliJ Idea Git is:

* that I can reorder the (local) commits

* mark with the mouse and right-click to squash them

No other git tool I know has these features.

magit does similar things with interactive rebases, although it is keyboard driven (I never tried to use the mouse). Another nice feature is the instant fixup where you can easily commit+rebase+fixup (think of commit --amend, but against any commit).

FYI, command-line Git is where fixup and autosquash come from:

https://blog.sebastian-daschner.com/entries/git-commit-fixup...

Magit makes the feature easier to use and more discoverable, though.

yes of course, the magit rebase buffer is literally the git rebase file with a custom emacs mode on top for interactivity.

because Magit is so much more convenient and user friendly than the CLI?

You don't have to learn all the plugins, I only use magit.

magit with emacs: C-x g, c c y, <message> C-c C-c

git over command line: Alt + Tab(shell), git commit -a -m "<message>" RET

You see the problem. Even assuming the message is short and typed on the command line without invoking the editor, the number of keystrokes is more. Of course number of keystrokes is a minor thing, when you compare rebase and other operations.

downvote? why?

Magit is a git porcelain inside emacs: https://magit.vc/

Thanks. Can't say I'm surprised of developers not including relevant links on their readme page.

To me this just says that they assume magit is so well known that everyone knows what they are referring to.

https://github.com/TimUntersberger/neogit/pull/159

As an alternative, there's no reason why one couldn't use neovim and magit (using Emacs only for magit). Emacs is an application framework, there's no reason why one has to use the "editor" application if all you want to use is the "magit" applciation.

IMO vim is better paired with tmux and the command line git, whereas with emacs it’s more common to open terminal buffers and use magit. Vim is more of a beefy editor while emacs is more of an environment. This is reflected in the way that both programs have designed their key binds and modalities. Emacs is much more amendable to many major modes whereas with vim, despite being a modal editor, things get crowded really fast.

Here's a editor-agnostic magit-inspired git TUI I wrote some time back:

https://github.com/hugit-project/hugit

I used to use it inside IntelliJ console when Emacs wasn't available.

As a vim user, I'm using lazygit[1] for handling git operations. What am I missing w.r.t a EMACS+Magit workflow?

[1]: https://github.com/jesseduffield/lazygit

I've started using lazygit for simple operations on Windows as magit can be slooooow there. I fall back to magit where needed.

Initial impression is that lazygit is much less mature and complete than magit. There's essentially nothing git can do that I can't make it do via magit. Lazygit in comparison is quite limited, often dropping out of the TUI to the command line to perform operations the TUI can't represent or not exposing them at all. It also seems to get confused or crash sometimes, and the UX isn't perfect - eg. it's scarily easy to perform remote-affecting operations like push with a single keypress and no confirmation. Finally, not being embedded in an editor renders lazygit less convenient for things like resolving conflicts (you can set EDITOR of course but then you're switching to another application to handle it).

That said, it is much faster than magit on Windows despite being, like magit, based on the git command line rather than libgit2 (there is an ongoing effort to move magit to the latter). I'm finding it very handy as an SSD to magit's spinning rust.

If you run Emacs on WSL it is way faster. Creating processes on Windows is more expensive compared to Linux. And magit suffers.

You can use a Windows X11 server for the GUI, but I think (?) there is native support for running GUI apps these days.

I've tried it but it's unfortunately not viable for my use. The (large) codebase needs to be in an ntfs filesystem for reasons beyond my control. With WSL1 the process startup is even slower than starting windows git and with WSL2 the process startup is fast but the filesystem access is slow. In both cases it ends up much slower even than native windows git.

Does anyone know how Vim Fugitive compares to Magit?

Completely different. Magit is basically a full git IDE, while fugitive is basically just a thin wrapper around the git command line.

I think what makes magit so cool, and much better than any IDE git integration I've ever seen, is that it's both of those things. It's interactive, easy to use, and efficient, but it also maps very directly to git commands you would otherwise be typing. It doesn't hide anything, it just makes everything more convenient.

This is a little confusing to me. Isn't the main reason why people use (neo)vi(m) that they reject the Emacs approach of merging everything into the editor (i.e. integration over separation)? So, if you're going to give up on your desire for disintegration, why not just switch to Emacs and use Evil to get emulation of the vim modal interface? Then, you're getting the original, fully-functional, non-WIP Magit, plus a more featureful extension ecosystem and a more robust scripting language besides.

Am I missing something?

The website does not really explain why you would want git inside vim.

I use gitui and while diffing could sometimes be better in vim, vim is a text editor and IMO not at all suited for this kind of task.

https://github.com/extrawurst/gitui

What is « Magit »?? Can’t find any information about it on this GitHub repository.

https://magit.vc/

Magit is the git layer/plugin for Emacs.

I don't know about others but personally magit changed the way I think about git and version control.

Yeah for me magit was one of those "magical" Emacs apps that really keeps me sticking with Emacs despite how slow it can be when you load it up with many extensions (compared to VSCode).

I hope the native comp in Emacs 28 helps somewhat in the speed aspect. The ports over to Deno and other JS stuff look interesting too [0] https://emacs-ng.github.io/emacs-ng/

You probably know this already, but Doom Emacs loads for me in less than a second.

Yeah I use Doom as well, but I've bogged it down with too many extensions and not enough time spent trying to load it smartly.

Running it as a systmed service helps (to avoid starting up a new instance vs. connecting to the service).

> I don't know about others but personally magit changed the way I think about git and version control.

Why? What changed in your view?

Git front-end that runs on the Emacs platform.

Reply on news.ycombinator.com