9 ms·

A work-in-progress Magit clone for Neovim

104 points by JNRowe 5y ago

mthld 5y ago
What is « Magit »?? Can’t find any information about it on this GitHub repository.
- bobnamob 5y ago
  https://magit.vc/ 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.
  - _huayra_ 5y ago
    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/ https://emacs-ng.github.io/emacs-ng/
    - kirubakaran 5y ago
      You probably know this already, but Doom Emacs loads for me in less than a second.
      - _huayra_ 5y ago
        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).
  - BossingAround 5y ago
    > 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?
- beermonster 5y ago
  Git front-end that runs on the Emacs platform.
ed 5y ago
Magit is a git porcelain inside emacs: https://magit.vc/ https://magit.vc/
- mihaifm 5y ago
  Thanks. Can't say I'm surprised of developers not including relevant links on their readme page.
  - celeritascelery 5y ago
    To me this just says that they assume magit is so well known that everyone knows what they are referring to.
  - schubart 5y ago
    https://github.com/TimUntersberger/neogit/pull/159 https://github.com/TimUntersberger/neogit/pull/159
unmole 5y ago
Does anyone know how Vim Fugitive compares to Magit?
- pta2002 5y ago
  Completely different. Magit is basically a full git IDE, while fugitive is basically just a thin wrapper around the git command line.
  - jorams 5y ago
    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.
ducktective 5y ago
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 https://github.com/jesseduffield/lazygit
- omnicognate 5y ago
  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.
  - beermonster 5y ago
    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.
    - omnicognate 5y ago
      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.
deleted 5y ago
[deleted]
ilovecaching 5y ago
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.
tut-urut-utut 5y ago
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.
- ddek 5y ago
  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?
  - masklinn 5y ago
    Beyond being able to open merge tools? No.
  - formerly_proven 5y ago
    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.
- deleted 5y ago
  [deleted]
- jhasse 5y ago
  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.
- masklinn 5y ago
  > 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.
laktak 5y ago
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 https://github.com/extrawurst/gitui
ackyshake 5y ago
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 https://github.com/tpope/vim-fugitive [2]: https://github.com/jonas/tig https://github.com/jonas/tig
- rjzzleep 5y ago
  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
- probotect0r 5y ago
  I have started using lazygit in tmux splits or neovim terminals and I love it!
- sodapopcan 5y ago
  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.
  - imbnwa 5y ago
    Also `blame` and `grep`
divs1210 5y ago
Here's a editor-agnostic magit-inspired git TUI I wrote some time back: https://github.com/hugit-project/hugit https://github.com/hugit-project/hugit I used to use it inside IntelliJ console when Emacs wasn't available.
catern 5y ago
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.
fouric 5y ago
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?

104 points by JNRowe 5y ago

mthld 5y ago

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

bobnamob 5y ago
https://magit.vc/ 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.
- _huayra_ 5y ago
  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/ https://emacs-ng.github.io/emacs-ng/
  - kirubakaran 5y ago
    You probably know this already, but Doom Emacs loads for me in less than a second.
    - _huayra_ 5y ago
      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).
- BossingAround 5y ago
  > 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?
beermonster 5y ago
Git front-end that runs on the Emacs platform.

ed 5y ago

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

mihaifm 5y ago
Thanks. Can't say I'm surprised of developers not including relevant links on their readme page.
- celeritascelery 5y ago
  To me this just says that they assume magit is so well known that everyone knows what they are referring to.
- schubart 5y ago
  https://github.com/TimUntersberger/neogit/pull/159 https://github.com/TimUntersberger/neogit/pull/159

unmole 5y ago

Does anyone know how Vim Fugitive compares to Magit?

pta2002 5y ago
Completely different. Magit is basically a full git IDE, while fugitive is basically just a thin wrapper around the git command line.
- jorams 5y ago
  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.

ducktective 5y ago

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 https://github.com/jesseduffield/lazygit

omnicognate 5y ago
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.
- beermonster 5y ago
  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.
  - omnicognate 5y ago
    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.

deleted 5y ago

[deleted]

ilovecaching 5y ago

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.

tut-urut-utut 5y ago

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.

ddek 5y ago
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?
- masklinn 5y ago
  Beyond being able to open merge tools? No.
- formerly_proven 5y ago
  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.
deleted 5y ago
[deleted]
jhasse 5y ago
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.
masklinn 5y ago
> 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.

laktak 5y ago

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 https://github.com/extrawurst/gitui

ackyshake 5y ago

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 https://github.com/tpope/vim-fugitive [2]: https://github.com/jonas/tig https://github.com/jonas/tig

rjzzleep 5y ago
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
probotect0r 5y ago
I have started using lazygit in tmux splits or neovim terminals and I love it!
sodapopcan 5y ago
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.
- imbnwa 5y ago
  Also `blame` and `grep`

divs1210 5y ago

Here's a editor-agnostic magit-inspired git TUI I wrote some time back: https://github.com/hugit-project/hugit https://github.com/hugit-project/hugit I used to use it inside IntelliJ console when Emacs wasn't available.

catern 5y ago

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.

fouric 5y ago

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?