

What's new in Magit 2.x - cp9
https://www.masteringemacs.org/article/what-new-in-magit-2x

======
arocks
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.

------
branchless
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.

~~~
agumonkey
Time for a magit-legacy I guess.

------
jmount
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....](http://magit.vc/manual/magit/Updating-from-an-older-release.html)
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?

~~~
branchless
Assuming you are using the built-in package manager.

list-packages

Then press "h" for key-binding info such as "d" for delete.

~~~
jmount
Thank you, that seemed to help.

------
davexunit
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.

~~~
tarsius
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...](https://raw.githubusercontent.com/magit/magit/master/Documentation/RelNotes/2.1.0.txt)

\- Update instructions:
[http://magit.vc/manual/magit/Installation.html](http://magit.vc/manual/magit/Installation.html)

\- Homepage: [http://magit.vc](http://magit.vc)

------
agumonkey
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 :)

~~~
tarsius
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](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.

~~~
agumonkey
I don't know but in the end I stopped caring about themes, vanilla emacs
(light) is good 99% of the time.

------
kenko
There's some less great new stuff in 2.x, too, sadly:
[https://github.com/magit/magit/issues/2076](https://github.com/magit/magit/issues/2076)

~~~
tarsius
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.

------
mostafah
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.

~~~
blaenk
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.

~~~
solutionyogi
That's very interesting. What did Emcas offer you that Vim could not?

~~~
blaenk
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](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...](http://bling.github.io/blog/2013/10/27/emacs-as-my-leader-vim-survival-
guide/) ].

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/](http://magit.vc/) Or flycheck's [
[http://www.flycheck.org/](http://www.flycheck.org/) ] documentation here [
[http://www.flycheck.org/manual/latest/index.html](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...](http://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-
Functions.html) ], 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.

------
toolslive
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 ?

~~~
wging
Meta-answer: type 'b' in the magit status buffer and take a look at the help.
Or ? for a list of commands, including 'b'. Set-upstream is how you make it so
pushes go to a specific place. Can't be more specific right now, but this
should get you where you need.

