What are the advantages of using this plugin over using git in the terminal directly? The time to switch windows is always pretty marginal with Cmd-Tab, so that doesn't seem like a big enough win to me. (I'm honestly curious, I can't think of the big ones, but if I could I might switch.)
I could imagine diffing being a way better experience straight from the file you want to diff, and with code highlighting. That definitely sucks from the command line, but it's also pretty rarely needed.
Anything else?
The big disadvantage I see is that this is not going to be on anyone else's computer when I'm pairing or just messing around with them, so if I get accustomed to not using command-line interface then I get screwed when I'm not on my own computer...
Edit: the quick-commit feature looks pretty cool as a way to encourage making smaller commits, since I always forget to commit in smaller pieces.
There are numerous advantages one of being that magit uses multiple buffers to show contextual information. For example I can get a nice ASCII view of the commit log in one buffer (in all the available formats) and see the diffs for each commit with glorious colour-highlighting in the other, side-by-side. The diff buffer updates as I scroll through the history.
Easier to remember mnemonics for common tasks.
I can use magit-blame-mode to see the blame information inline with the file as I edit it.
Diffs are super-easy and I can jump right to any file to fix things as I come across them from the logs or the status view.
Plus emacs... so I get hooks into magit that I can use from other packages like org-mode, etc.
I find the command-line to be tedious and slow now. I'd rather use a smart front-end with sane defaults and a nice interface.
> What are the advantages of using this plugin over using git in the terminal directly?
Speaking generally to editor integrations and VCS GUI tools, the prime advantages vs. the CLI tools are:
1) Uninterrupted workflow for common tasks. Select files for commit, review the diffs, then commit all without leaving the editor.
2) Better visualization and interactive workflow. Examples include, good intra-line, side-by-side diff. Being able to `git blame` then trivially explore the associated commits and surrounding history for those commits. Yes, it's possible to do all of this from the command line, but it's often clunky compared to well-thought out tooling. With some VCS systems and projects, graphical display and navigation of history is helpful for understanding the relative state of branches, tracking down obscure bugs, etc.
That said, I'm not a fan of glossy GUI tools that hide the working model of the underlying VCS. For the most part, not using the CLI is a great way to never really "get" version control as a powerful workflow tool. Perforce's P4V GUI tool gets credit on this point. The last time I used it, there was a console that showed the command line run and results for every GUI action. This happened to be a nice learning tool, providing relevant, live examples of basic and advanced usage.
Lots of people prefer to interact with their VCS tools via a GUI, and a reasonably large subset of those people prefer for the integration to be built in to their IDE/editor.
Probably 60% of the people at the company I work at don't even know how to use Git or SVN from the command line.
This seems like a decent enough bridge between those two worlds.
I could imagine diffing being a way better experience straight from the file you want to diff, and with code highlighting. That definitely sucks from the command line, but it's also pretty rarely needed.
Anything else?
The big disadvantage I see is that this is not going to be on anyone else's computer when I'm pairing or just messing around with them, so if I get accustomed to not using command-line interface then I get screwed when I'm not on my own computer...
Edit: the quick-commit feature looks pretty cool as a way to encourage making smaller commits, since I always forget to commit in smaller pieces.