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

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

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.

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.

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.

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.

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.

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

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

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

Iirc you can edit the patch in git add -p. So fine editing is possible.

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.

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.

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.

Why just not use TRAMP to use your personal emacs to edit files on remote systems?

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.

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

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

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.

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

> gitgutter is no git diff

FYI in gitgutter you can preview the diff for any change (and also edit the hunk and stage it).

Magit has a blame annotation mode, no gitgutter, although there's an unrelated emacs port of that one.

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.

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?).

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.

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.

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.

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.

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.

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?

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.

Beyond being able to open merge tools? No.

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.

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

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.

yes of course, the magit rebase buffer is literally the git rebase file with a custom emacs mode on top for interactivity.

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.

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.