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.
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...
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.
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.
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.
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.
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.
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.
Not necessarily tedious - you can just use "git add -p" to stage hunks individually.
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.
* 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).
Magit is actually one of the best pieces of software I've ever used.
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?
FYI in gitgutter you can preview the diff for any change (and also edit the hunk and stage it).
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.
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?).
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.
I've not found that they apply to Magit.
That may just be that most Magit users are also heavy CLI users, though.
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.
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.
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.
* 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.
https://blog.sebastian-daschner.com/entries/git-commit-fixup...
Magit makes the feature easier to use and more discoverable, though.
You don't have to learn all the plugins, I only use magit.
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.