[HN Gopher] A work-in-progress Magit clone for Neovim
___________________________________________________________________
A work-in-progress Magit clone for Neovim
Author : JNRowe
Score : 102 points
Date : 2021-07-06 11:29 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mthld wrote:
| What is << Magit >>?? Can't find any information about it on this
| GitHub repository.
| bobnamob wrote:
| 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.
| BossingAround wrote:
| > 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?
| _huayra_ wrote:
| 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/
| kirubakaran wrote:
| You probably know this already, but Doom Emacs loads for me
| in less than a second.
| beermonster wrote:
| Git front-end that runs on the Emacs platform.
| ed wrote:
| Magit is a git porcelain inside emacs: https://magit.vc/
| mihaifm wrote:
| Thanks. Can't say I'm surprised of developers not including
| relevant links on their readme page.
| celeritascelery wrote:
| To me this just says that they assume magit is so well known
| that everyone knows what they are referring to.
| ackyshake wrote:
| 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
| lowski_ wrote:
| 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!
| probotect0r wrote:
| I have started using lazygit in tmux splits or neovim terminals
| and I love it!
| rjzzleep wrote:
| 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
| sodapopcan wrote:
| 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 wrote:
| Also `blame` and `grep`
| sodapopcan wrote:
| I mentioned blame! :)
|
| I also make heavy use of :Gedit for easily looking at files
| on other branches.
| imbnwa wrote:
| Missed that. Never used :Gedit, appears hella convenient
| sodapopcan wrote:
| :Gedit master:% is a common one I use to see what the
| current file looks like on master.
| divs1210 wrote:
| 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.
| ilovecaching wrote:
| 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 wrote:
| 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.
| coldtea wrote:
| > _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...
| bananadonkey wrote:
| 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.
| omnicognate wrote:
| 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).
| formerly_proven wrote:
| 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.
| NateEag wrote:
| 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.
| 3v1n0 wrote:
| 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.
| ddek wrote:
| 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 wrote:
| Beyond being able to open merge tools? No.
| formerly_proven wrote:
| 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.
| trey-jones wrote:
| 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.
| [deleted]
| trackno53324 wrote:
| 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.
| trackno53324 wrote:
| downvote? why?
| jhasse wrote:
| 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 wrote:
| > 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.
| zelphirkalt wrote:
| > 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.
| I_complete_me wrote:
| 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
| tbabej wrote:
| > 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.
| rerx wrote:
| 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.
| xemdetia wrote:
| 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.
| rjzzleep wrote:
| 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.
| rerx wrote:
| 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.
| fouric wrote:
| Why just not use TRAMP to use your personal emacs to edit
| files on remote systems?
| NateEag wrote:
| `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.
| scooble wrote:
| Iirc you can edit the patch in git add -p. So fine
| editing is possible.
| kenniskrag wrote:
| 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.
| gpderetta wrote:
| 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).
| NateEag wrote:
| 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.
| gpderetta wrote:
| yes of course, the magit rebase buffer is literally the
| git rebase file with a custom emacs mode on top for
| interactivity.
| tomxor wrote:
| > ... 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?
| arc-in-space wrote:
| Magit has a blame annotation mode, no gitgutter, although
| there's an unrelated emacs port of that one.
| airblade wrote:
| > gitgutter is no git diff
|
| FYI in gitgutter you can preview the diff for any change (and
| also edit the hunk and stage it).
| monsieurbanana wrote:
| 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.
| formerly_proven wrote:
| 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?).
| rjknight wrote:
| 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.
| tomxor wrote:
| 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.
| omnicognate wrote:
| 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.
| NateEag wrote:
| 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.
| gpderetta wrote:
| 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.
| synthc wrote:
| 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.
| laktak wrote:
| 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
| unmole wrote:
| Does anyone know how Vim Fugitive compares to Magit?
| pta2002 wrote:
| Completely different. Magit is basically a full git IDE, while
| fugitive is basically just a thin wrapper around the git
| command line.
| jorams wrote:
| 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.
| fouric wrote:
| 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?
| catern wrote:
| 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.
| ducktective wrote:
| 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
| omnicognate wrote:
| 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 wrote:
| 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 wrote:
| 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]
___________________________________________________________________
(page generated 2021-07-08 23:02 UTC)