[qyron]

Seeing all the praise for Magit in these and numerous other threads, could someone please elaborate on its standout features that are missing from other editors/IDEs (VSCode+extensions or JetBrains)?

For example, in my current VSCode + GitLens setup (must admit that I have a corporate license for GitKraken, which enables full GitLens functionality). I use these features 99% of the time.

1. Convenient diff/merge with character-level diffs and visual indication of moved code.

2. A graphical commit tree with filtering, searching, numerous hovers with lots of information, and buttons to quickly jump to all sorts of diffs.

3. Interactive rebase (GUI for selecting those pick/squash/reword etc.)

4. Editing new and existing commit messages in vscode, which allows me to use better commit message formatters, LanguageTool and LLM extensions for rewriting/paraphrasing.

When I see comments like "Magit is the only thing that keeps me from leaving Emacs," I honestly wonder what they're going to miss.

[iLemming]

> When I see comments like "Magit is the only thing that keeps me from leaving Emacs," I honestly wonder what they're going to miss.

The "killer feature" is how it makes git feel like a natural extension of text editing rather than a separate tool. Other git UIs exist, but none integrate the "edit-review-commit" cycle as seamlessly. It's less about any single feature and more about how it transforms git from something you "switch to" into something that's just... there.

A huge part of what makes Magit special - it's not just a UI, it's a complete git API for Emacs - Magit is a library, not only I can easily extend Magit's own functionality, I can just call its functions, advice them, etc.

For example: If I want in my tab (there's tab-bar-mode in Emacs) some git-based info, I can easily do it. Or I can hook into magit-post-commit-hook to trigger custom actions. This composability is impossible with standalone git clients. You're not just using a git interface - you're programming with git as a first-class citizen in your editor. Other tools give you a UI; Magit gives you building blocks.

There are integrations in Emacs that Magit author and maintainers never even thought about initially. Like for example in Dired, where you'd be listing directories, you can mark some files and dirs, and stage those files or show the git log pertaining only marked items.

But again, it's not so much about features that already exist in Magit, but the way how one can easily extend things to add features that are not there - and there are tons of examples - note-taking workflows (where using Org-roam/Denote one can stage specific thoughts from their daily notes, creating atomic commits of ideas); literate devops (where you keep tf/ansible scripts in Org-mode src blocks and commit directly from the same document); academic writing (e.g., with LLM integration); time tracking (where people hook to magit-post-comit to automatically log time entries); config management (where you use magit's cherry-pick to selectively sync specific configs between work/personal machines), etc., etc.

[qyron]

So I see that Magit provides not just the git GUI client but also API functions which can be used in other plugins and user config. However I'd like to dig a bit deeper into the real value of this for a user of "stays with Emacs only Magit"-type. So forgive me for being too picky.

Putting all Org-mode related features aside, since obviously Org-mode is much more Emacs-exclusive feature than Git support, here's what I see from your comments.

> If I want in my tab (there's tab-bar-mode in Emacs) some git-based info, I can easily do it.

I understand tab-bar is similar to tab bar in modern GUI editors - just a list of open files. Modern editors already mark dirty/staged files in the tab bar. Can you give an example of another information that one might want to add to each file?

> Like for example in Dired, where you'd be listing directories, you can mark some files and dirs, and stage those files

I assume Dired is some kind of file browser. While I appreciate the ability to integrate Magit with any file browser plugin, staging/unstaging files from the file tree sidebar is basic functionality of any editor with Git support. It's hard for me to imagine any life-changing improvement in this area.

> or show the git log pertaining only marked items.

Yes, that's neat. But IMO it's a very advanced feature that's used pretty rarely. Most of the time one wants to see either git log for current file or select some file in file tree in sidebar and see its log.

> Or I can hook into magit-post-commit-hook to trigger custom actions

You provided some examples for integration of Magit with note-taking. Advanced note-taking in emacs is a whole different world and I assume that person wanting to leave Emacs (but staying for Magit ;) will be ok with using some more mainstream note-taking software (like Obsidian etc.). So when using a code editor/IDE for its' original purpose - editing source code in some programming language, what would be a popular example of Magit hook that is not achievable with the existing Git hooks mechanism?

To clarify again my doubts, I think that someone who has mastered Elisp, maintains his own Emacs config and heavily customizes Emacs to his liking, would never consider moving to VScode or Jetbrains. However, all those Doom users evaluating to move to "mainstream" editors, who do only minor adjustments (like options, keybindings), do they get something substantial from Magit that they can't achieve in those editors?

[sameerds]

> However I'd like to dig a bit deeper into the real value of this for a user of "stays with Emacs only Magit"-type.

That right there is the problem. I have been an Emacs user for decades. Magit is awesome because of Emacs, not inspite of Emacs. Whatever this person is saying, either they have not given any real thought to their own experience, or they really don't care about anything other than Magit as a piece of software that they prefer using. If it's the latter, then only that person can tell you what is so great about Magit. But that line of thought is really hard to understand and counter for a typical developer who cares about their entire coding experience and not just any one package.

> However, all those Doom users evaluating to move to "mainstream" editors, who do only minor adjustments (like options, keybindings), do they get something substantial from Magit that they can't achieve in those editors?

No. I would be very skeptical of people who make such claims.

[iLemming]

I appreciate your curiosity, and I understand your skepticism, but you're asking me of something I can't know - I cannot compare one or multiple selected aspects of Emacs, because in my view that is a pointless mental exercise — I have the holistic comprehension of Emacs features and only can speak about the emergent properties that arise from their integration. To isolate individual features would be like asking a fish to compare water to air - I exist within this environment so completely that I cannot meaningfully separate its components from the unified experience they create. What I can tell you is how this ecosystem shapes my responses, how the interwoven capabilities of buffers, modes, and elisp create a context that is inseparable from my function. The question isn't which feature is superior, but rather how they synthesize into something greater than their parts.

Emacs can manage many different tasks — work as a web browser, email client, search agent, REST API tester, project manager, PDF reader, version-control tool, LLM frontend, chat app, and even text editor. Trying to evaluate it in any single function wouldn't be fair, because in isolation, any of these roles are imperfect - Emacs is most definitely not the best tool for any individual task. However, for me and many others, Emacs is first and foremost a "Lisp Machine" (technically you can't call it that, but that's semantics for a different conversation). When one truly grasps and appreciates this specific aspect, they can transform it into an incredibly versatile tool - it eventually does become the best web browser, email client, search agent, etc.

That's all philosophy, let me try to adress more concrete questions.

> imilar to tab bar in modern GUI editors - just a list of open files.

No, tab-bar in Emacs (just like many other things) is very extensible medium. You can use it to show almost anything you like. I use tabs for separating my project contexts. I can easily make it show project's git info, like current work-tree.

> I assume Dired is some kind of file browser.

It's not just a file browser, it's a "DiREctoryEDitor" — your file tree (including subdirs) is fully editable, you can use whatever features of your editor - macros, multiple cursors, search-n-replace, etc. You can change a bunch of filenames and apply your changes, they'll be reflected on the disk.

> it's a very advanced feature that's used pretty rarely.

That's just an example of simple integration of different packages. There are many different features like that, some of them you need to use just once to understand how powerful they are, even though rarely used.

> what would be a popular example of Magit hook that is not achievable with the existing Git hooks mechanism?

A popular example would be automatically updating buffer-local variables or Emacs-specific project settings when switching branches.

For instance, when switching from a "main" branch to a "feature/python-3.12" branch, a Magit hook could:

- Automatically switch your Python virtualenv/conda environment

- Update python-shell-interpreter to point to the correct Python version

- Adjust linting/formatting tools (switching between different ruff/flake8 configs)

- Change compile commands or test runners

While you could achieve some of this with Git hooks by writing shell scripts that modify files, Magit hooks can directly manipulate Emacs' internal state without the overhead of external processes or temporary files. They integrate seamlessly with Emacs' project.el, eglot/lsp-mode, and other development tools.

This is particularly valuable in polyglot projects where different branches might use different language versions or toolchains.

> do they get something substantial from Magit that they can't achieve in those editors?

For Doom users who only make minor adjustments like keybinds, Magit alone probably isn't a strong enough reason to stay on Emacs. As I mentioned earlier, focusing on just one aspect of Emacs is a misguided approach, which explains why these users eventually discover more specialized apps and abandon it. I regularly see comments like "I've used Emacs for nearly a decade, but still left..."

In a head-to-head (Git-focused) comparison, perhaps Magit is not going to win all the hearts. Besides, where Magit truly shines (interactive rebasing, selective staging, complex history manipulation) are features that power users love but casual and new users might rarely touch.

No one really gains anything substantial from Emacs after just a week or two of use. Emacs is a journey that sometimes takes years of simply persuading yourself to give it another try. Though I personally find it a worthwhile investment, I don't think adopting Emacs merely because "people say it has a killer Git interface" is the right approach. Everyone has different idea what makes a "killer Git interface," and Emacs might not provide what they're looking for — even though it undoubtedly has the potential to become the killer Git interface they seek.

[boops_u]

> I have the holistic comprehension of Emacs features and only can speak about the emergent properties that arise from their integration. To isolate individual features would be like asking a fish to compare water to air - I exist within this environment so completely that I cannot meaningfully separate its components from the unified experience they create. What I can tell you is how this ecosystem shapes my responses, how the interwoven capabilities of buffers, modes, and elisp create a context that is inseparable from my function. The question isn't which feature is superior, but rather how they synthesize into something greater than their parts.

yes, this is emacs poetry :)

[iLemming]

Now re-reading it, that entire paragraph sounds like high-horse highfalutin. I should've used a simpler tone. Emacs is not that sophisticated; it's not "a lifetime achievement" to brag about - it's a tool. Tools need mostly two things: care and use. But the choice for doing either ultimately belongs to the one who chooses to use a tool. Use whatever tools, programming languages, distros, techniques make you happy. I like mine. I'm just happy to share that feeling with people. I'm not saying my choices could make someone else happy, but they made me. I just wish I had listened sooner to someone passionate and persuasive who could tell me about how some choices can make you happier.

[jasonm23]

It's beautiful and why there's not all that many Emacs users... it requires a commitment, at the very least.

[iLemming]

> it requires a commitment

What serious tool doesn't?

[Ferret7446]

Magit provides almost complete discovery, interactivity, and feedback for all Git operations.

One of the major barriers to learning CLI Git is that it's hard to discover the available commands and options, and when you run them, it's unclear what what state is changing.

Magit makes it easy to access almost all Git features via interactive keypress driven, self documenting menus, and it displays visually all of your repository state. It also provides easy access to "no brainer" features like committing single chunks or lines, "cherry picking" or reverting single chunks or lines from any arbitrary commit, committing fixups to earlier commits with a single command, etc.

Magit is to other IDE integrations what other IDE integrations is to the Git CLI.

[sameerds]

I have tried explaining magit to my fellow developers. And they kept showing me how they do similar things in their favourite IDE. Turns out that Magit in itself is not compelling. You have to first appreciate Emacs, and then you notice how perfectly well Magit "raises" git to the Emacs abstractions. I love Magit and rarely use the git commandline. But that's because Emacs fits my brain perfectly; the way Emacs deals with "things" (pun intended) is exactly how my brain works. And then Magit just makes version control feel like Emacs front and center.