▲ 104 points
back
77 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>
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.
Also `blame` and `grep`
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>
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.
> 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.
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).
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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.
Git front-end that runs on the Emacs platform.