What's new in Magit 2.x(masteringemacs.org)
masteringemacs.org
What's new in Magit 2.x
https://www.masteringemacs.org/article/what-new-in-magit-2x
8 comments
Even if you don't use Emacs, I believe you _have_ to try magit. It will quickly become an essential part of your git workflow. You could zoom out to grasp the overall state of your project, dive into specific details and perform intricate surgery of your git history, all with single-key presses. It is pure genius.
I love magit. One gripe with the upgrade is 2.x requires a recent version of git. I use magit at work and we have to all use the same git version. It's not a recent version so I can't use the latest magit.
This is unfortunate. I wonder if the maintainers could simply disable some of the newer features if the git version is say 1.8 which would allow git luddites to benefit from the other enhancements.
This is unfortunate. I wonder if the maintainers could simply disable some of the newer features if the git version is say 1.8 which would allow git luddites to benefit from the other enhancements.
Time for a magit-legacy I guess.
I know this will be considered un-gracious and get me the "learn emacs NOOB" award (an editor I have been using for 20 years, just not a huge fan of the package environment).
But, I notice emacs packages don't give the specific steps to follow. For instance http://magit.vc/manual/magit/Updating-from-an-older-release.... says "So please uninstall the packages magit, git-commit-mode, and git-rebase-mode." No mention of what specific command will do that, what environment variable may tell you the directory location or so on. I know writing documentation is unpleasant, but it is really frustrating when you don't connect that last inch with the exact commands.
Even the linked article instructions are a problem. For me the command "M-x magit-version" is not defined until after I run "M-x magit-status". Even then the version reported is "Magit 21050722.2133". Care to hazard a guess if this is a 2.X version of Magit? Is it 2.133?
But, I notice emacs packages don't give the specific steps to follow. For instance http://magit.vc/manual/magit/Updating-from-an-older-release.... says "So please uninstall the packages magit, git-commit-mode, and git-rebase-mode." No mention of what specific command will do that, what environment variable may tell you the directory location or so on. I know writing documentation is unpleasant, but it is really frustrating when you don't connect that last inch with the exact commands.
Even the linked article instructions are a problem. For me the command "M-x magit-version" is not defined until after I run "M-x magit-status". Even then the version reported is "Magit 21050722.2133". Care to hazard a guess if this is a 2.X version of Magit? Is it 2.133?
I think you have a fair point. Very often emacs blog articles assume quite a deep knowledge, whereas ones about let's say bash, linux distro Foo, will be much more procedural step by step command.
Assuming you are using the built-in package manager.
list-packages
Then press "h" for key-binding info such as "d" for delete.
list-packages
Then press "h" for key-binding info such as "d" for delete.
Thank you, that seemed to help.
Besides Emacs itself, Magit is the greatest tool in my arsenal for making clean patches and making me a more productive programmer in general. It's made doing more advanced git tasks so much easier, interactive rebasing and staging/unstaging hunks in particular. Can't live without it.
Thanks. It's always nice to hear from satisfied users.
This is for the benefit of other users (since you have probably already found these resources):
- Release notes: https://raw.githubusercontent.com/magit/magit/master/Documen...
- Update instructions: http://magit.vc/manual/magit/Installation.html
- Homepage: http://magit.vc
This is for the benefit of other users (since you have probably already found these resources):
- Release notes: https://raw.githubusercontent.com/magit/magit/master/Documen...
- Update instructions: http://magit.vc/manual/magit/Installation.html
- Homepage: http://magit.vc
Very very minor nitpick, magit-status theme (gray, brown, black) is not very welcoming. I don't use themes so I guess these are defaults magit values. You need to put some rainbow in there :)
Yeah, that's a bit boring. Personally I use the solarized theme, and have invested more time on that, than the default themes. That's also what we use for the screenshots (http://magit.vc/screenshots).
Another reason why the default theme (both in it's light and dark variant) are a bit ugly is that they should work even for users who have customized individual faces. Sticking with gray backgrounds seems like a safe bet.
Another reason why the default theme (both in it's light and dark variant) are a bit ugly is that they should work even for users who have customized individual faces. Sticking with gray backgrounds seems like a safe bet.
I don't know but in the end I stopped caring about themes, vanilla emacs (light) is good 99% of the time.
There's some less great new stuff in 2.x, too, sadly:
https://github.com/magit/magit/issues/2076
I am not very happy about it, but I have just installed a change that forces everybody to opt-in to the new push behavior.
Kind of OT, but has anybody read this book? How good is it? Seems very interesting and the articles on the site are good too, but since it’s not on Amazon I haven’t seen any reviews.
I bought it and read about half of it. It's pretty good. I feel like it was the straw that really helped me turn off evil mode for good.
I read it and it helped me switched to emacs after using vim for 10 years. It's great, as it teaches you the emacs 'mindset' instead of just being a dry procedural manual.
That's very interesting. What did Emcas offer you that Vim could not?
TL;DR: Watch this video: the stated reasons for switching are very similar to my own. It wasn't until I watched this video and read the book that I took the plunge to switch to emacs. It was the fact that with emacs I could have vim _plus_ much more and better functionality. https://www.youtube.com/watch?v=JWD1Fpdd4Pc
I'll have to write a blog post about it sometime, but basically while I absolutely _love_ the vim 'editing interface', that is, not the GUI, but the modal editing, the bindings, motions, objects, relative line numbers, and so on, everything else aside from that, primarily plugins, always felt like ad-hoc hacks to me. I've contributed to a couple of vim plugins so I've seen it first hand, to the point where plugin authors I've worked with have expressed feelings of wanting to switch to emacs to just make things easier. Indeed, some have, such as the vim-airline author [ http://bling.github.io/blog/2013/10/27/emacs-as-my-leader-vi... ].
Whereas plugins in vim oftentimes gave me the impression that they were stopgaps and hacky workarounds to get vim to do something it wasn't meant to do, emacs packages feel very natural, comprehensive, and well designed. Just take this article for example. As awesome as vim-fugitive is for vim, I feel that it's good _for being a vim plugin_, but it has _nothing_ on the equivalent on emacs: magit. Take a look at it's comprehensive documentation: http://magit.vc/ Or flycheck's [ http://www.flycheck.org/ ] documentation here [ http://www.flycheck.org/manual/latest/index.html ]
It seems like everyone puts up with everything else about vim just to have the good parts of vim that are generally very poorly emulated by other editors. The evil package for emacs changed that for me, as it's the most faithful vim emulator I've seen. Now I have a superset of vim; the vim that I love in an environment that is _much_ more suitable for my development workflow: magit, error checking, tags, searching, and more.
If you're just a vim user, you probably don't really think about or realize what you're missing out on by not using emacs. One of my favorite things about emacs that the book really emphasizes is that it is completely self-documenting. Every function, every key binding, every command, every variable, everything is documented and easy to find. Vim of course has `:help` as well, but emac's documentation is on an entirely different level. I can press `C-h k` for example, then press a binding on my keyboard, and it'll tell me what command I have it bound to, what that command does, and it'll have a link to the source code for that command that opens in emacs with syntax highlighting and everything. Of course I can also do the reverse: find what key a command is bound to; in fact I can search my bindings as I type using helm-descbinds. I can search emacs documentation easily with the `apropos` command and its variants. Oftentimes in vim I generally only looked things up only after I already knew _what_ to look up, whereas in emacs I can easily explore things on my own and figure things out.
Emacs has much better extensibility features in general. In vim sometimes I would find something a plugin did that I wanted to work differently, and I pretty much only had two options: 1) file PR and hope the author agrees with my changes or adds them in optionally or 2) fork the plugin. 2 was out of the question because I didn't want the maintenance burden of maintaining a fork, and 1 was too much trouble sometimes for simple modifications or were simply too opinionated to realistically be accepted by the author. So pragmatically I just treated plugins as set-in-stone. With emacs I have much more options at my disposal ranging from advising [ http://www.gnu.org/software/emacs/manual/html_node/elisp/Adv... ], hooks, and in the worst case just redefining symbols with emacs lisp.
I was and still am hopeful for Neovim, but it'll take ages for it to catch up to emacs in terms of robustness and ecosystem, let alone similar feature set of emacs (which is probably a non-goal of neovim anyways). It's just an entirely different 'environment' in the sense of features and packages available to you.
I wonder if in the future we could leverage neovim's API functionality to have completely true vim bindings/editing within emacs. That would be the absolute best case scenario that I could imagine.
That said, I definitely believe that the default emacs bindings are horrible. I at first wanted to try to go cold turkey, 100% emacs, but the editing in emacs is just horrible to someone like me familiar with the speed and precision of vim editing, so I gave in and used evil, which is amazing. That saying about emacs being "a great operating system, lacking only a decent editor" rings very true to my ears, and with evil I have both.
I'll have to write a blog post about it sometime, but basically while I absolutely _love_ the vim 'editing interface', that is, not the GUI, but the modal editing, the bindings, motions, objects, relative line numbers, and so on, everything else aside from that, primarily plugins, always felt like ad-hoc hacks to me. I've contributed to a couple of vim plugins so I've seen it first hand, to the point where plugin authors I've worked with have expressed feelings of wanting to switch to emacs to just make things easier. Indeed, some have, such as the vim-airline author [ http://bling.github.io/blog/2013/10/27/emacs-as-my-leader-vi... ].
Whereas plugins in vim oftentimes gave me the impression that they were stopgaps and hacky workarounds to get vim to do something it wasn't meant to do, emacs packages feel very natural, comprehensive, and well designed. Just take this article for example. As awesome as vim-fugitive is for vim, I feel that it's good _for being a vim plugin_, but it has _nothing_ on the equivalent on emacs: magit. Take a look at it's comprehensive documentation: http://magit.vc/ Or flycheck's [ http://www.flycheck.org/ ] documentation here [ http://www.flycheck.org/manual/latest/index.html ]
It seems like everyone puts up with everything else about vim just to have the good parts of vim that are generally very poorly emulated by other editors. The evil package for emacs changed that for me, as it's the most faithful vim emulator I've seen. Now I have a superset of vim; the vim that I love in an environment that is _much_ more suitable for my development workflow: magit, error checking, tags, searching, and more.
If you're just a vim user, you probably don't really think about or realize what you're missing out on by not using emacs. One of my favorite things about emacs that the book really emphasizes is that it is completely self-documenting. Every function, every key binding, every command, every variable, everything is documented and easy to find. Vim of course has `:help` as well, but emac's documentation is on an entirely different level. I can press `C-h k` for example, then press a binding on my keyboard, and it'll tell me what command I have it bound to, what that command does, and it'll have a link to the source code for that command that opens in emacs with syntax highlighting and everything. Of course I can also do the reverse: find what key a command is bound to; in fact I can search my bindings as I type using helm-descbinds. I can search emacs documentation easily with the `apropos` command and its variants. Oftentimes in vim I generally only looked things up only after I already knew _what_ to look up, whereas in emacs I can easily explore things on my own and figure things out.
Emacs has much better extensibility features in general. In vim sometimes I would find something a plugin did that I wanted to work differently, and I pretty much only had two options: 1) file PR and hope the author agrees with my changes or adds them in optionally or 2) fork the plugin. 2 was out of the question because I didn't want the maintenance burden of maintaining a fork, and 1 was too much trouble sometimes for simple modifications or were simply too opinionated to realistically be accepted by the author. So pragmatically I just treated plugins as set-in-stone. With emacs I have much more options at my disposal ranging from advising [ http://www.gnu.org/software/emacs/manual/html_node/elisp/Adv... ], hooks, and in the worst case just redefining symbols with emacs lisp.
I was and still am hopeful for Neovim, but it'll take ages for it to catch up to emacs in terms of robustness and ecosystem, let alone similar feature set of emacs (which is probably a non-goal of neovim anyways). It's just an entirely different 'environment' in the sense of features and packages available to you.
I wonder if in the future we could leverage neovim's API functionality to have completely true vim bindings/editing within emacs. That would be the absolute best case scenario that I could imagine.
That said, I definitely believe that the default emacs bindings are horrible. I at first wanted to try to go cold turkey, 100% emacs, but the editing in emacs is just horrible to someone like me familiar with the speed and precision of vim editing, so I gave in and used evil, which is amazing. That saying about emacs being "a great operating system, lacking only a decent editor" rings very true to my ears, and with evil I have both.
moving from magit 1.x to this magit made me accidentally push some commits to the master branch. This is because my fingers still want to exercise the magit 1.X key combo's. I'm sure I'm not the only one.
So what's the canonical way to:
create branch X,
switch to branch X,
and make it so my next push will go to origin/X ?