There's no such thing as "Magit for VSCode", it could be "Magit-like" or "Magit inspired", but never can replace Magit, simply because Magit is not an extension, it's an Emacs package.
Emacs doesn't have "extensions", because every package can be used as a library or radically change the behavior not only Emacs itself but other packages too. Magit's parts been used in other packages - transient.el has evolved into a separate package; magit-section is used in packages like code-review.el, forge, notmuch; magit-git - low-level git interface functions used by packages like diff-hl, git-gutter, etc.; process handling abstraction used by packages that need async process management; etc.
VSCode extensions run in isolation, you can't directly call functions of one extension from another, you can only use what an extension explicitly exposes via its public API (if any). In comparison, Emacs users can freely incorporate Magit's internal commands into their configs, extend them and combine multiple packages seamlessly.
In Emacs, one could write a 5-line function that checks Magit's current branch, queries Projectile for project type, and then calls different Magit commands based on context. In VSCode, something like that would require formal APIs, message passing between extensions, and cooperation from all involved extension authors. In Emacs, you wouldn't even have to save the function on disk before trying it out.
All of this is true. And it's also why inevitably all my more complicated emacs configurations inevitably end up broken in some way over time :-)
Emacs is paradoxical — it always works, yet at the same time, any parts of your config may prove to be broken at any given moment. Maintaining a complex Emacs config is a chore. And not because of Emacs itself, core of Emacs is remarkably stable, most issues are in the customization layer you control.
What you get in return though is far more valuable than any alternative — when something breaks, YOU can fix it. You're not waiting for a vendor or update. The system is transparent and malleable. Each fix teaches you something. Over time, you build deep understanding of your environment. The chores become easier. Unlike rigid software, Emacs molds to your exact workflow. The maintenance cost pays for a tool that works EXACTLY how you think.
Emacs is a professional chef's kitchen - A chef maintains their knives, adjusts recipes, deals with temperamental ovens. More work than a microwave dinner, but they can create ANYTHING. When the soufflé fails, they know why and can fix it.
"Yeah, well", some may say, "I don't want to be a chef, I just want to occasionally fix some bad cookies, using the 'easy-cookie-maker-kit', it just-works™, why not use it?".
I can tell you my perspective on that. I decided to "become a chef" and use "my own kitchen", because I'm tired of different types of cookie-maker-kits. It seems like everyone has a different opinion of what the cookie-maker-kit should look like, what it should do, what kind of cookies can you make with it. Every few years, the "ultimate" kit appears, promises to revolutionize cookie-making, then gets abandoned or dramatically changed. Your muscle memory becomes worthless. Your recipes need rewriting. The new kit can't make the cookies you loved.
But in my kitchen? My grandmother's rolling pin still works. The oven I learned five years ago still bakes the same way. When I discover a new technique, I add it to MY repertoire, not wait for someone to maybe include it in Cookie-Maker-Kit 3.0. Sure, I burned a few batches learning temperature control. Yes, I maintain my tools. But now I can make cookies, and bread, and soufflés, and things that don't even have names yet.
The cookie-kit users are still arguing about whether round or square cookies are "correct," while I'm over here making star-shaped ones because I felt like it today.
>Maintaining a complex Emacs config is a chore. I have given up and adopted Doom Emacs. Let cleverer people do the wrangling
I feel like Doom is maybe obsolescent on account of standard out of the box emacs having fairly easy to set up these days, with themes and LSP and etc just there out of the box and package-install just working.
But also I have absolutely zero desire to run with modal keybindings, which seems to be Doom's schtick.
No, Doom is not a final product of some sort. Going back to my "kitchen" analogy, Doom is like a recipe book - it's great for some ideation (you can check for example what kind of things used in Python module and build your own, or extend existing, 'official' module). It offers you some modularity - Doom-based configs are great for breaking down into reusable components. Doom's core also contains a lot of very nifty macros that allow you to reduce otherwise unavoidable boilerplate. Other than that, Doom is just the regular, good old Emacs - you still can do everything you could do before, with perhaps some better structure and code ergonomics.
Doom may become obsolete only if it keeps partitioning into separate packages, e.g., doom-modeline started as a core component of Doom, now it's a separate package. Similarly, nothing really preventing anyone from forking other core parts of Doom into separate packages.
Also, evil-mode keys are optional, anyone can use Doom without using vim keys, there's still good value in doing that.
That's also why I don't use it. It's not bad at all! It's just not how I want to use Emacs. It's not right for me.
I sure do get the appeal of an out-of-the-box Emacs setup that does everything with modern defaults, but the base installation gets better, more ergonomic, and more powerful by the year on its own.
"out-of-the-box Emacs setup" was never a thing that lured me into trying it. I liked the idea of modularity with Doom. Before that I never knew where to put things, how to split them, how to make them work with one another, how to disable features without breaking some others.
I have learned tons of things since then and on multiple occasions I thought about rebuilding things (with my now more extended knowledge) from scratch, but I'm afraid I will inevitably end up borrowing some core Doom macros, and end up recreating something that very much looks and feels like Doom, without being Doom, perhaps with a different package manager. That I believe is the only non-negotiable part of it today. Other than that, Doom is nothing but a very thin layer of abstraction. I don't even use Doom's own modules, instead I built the set of my own. Anyway, if you ever feel overwhelmed and decide to call another emacs.d bankruptcy, maybe give Doom a try. You can disable all the modules and build on top of that lean core, it still has objectively nice features - CLI tool is nice, macros like map! and add-hook! and defadvice! are very cool. It loads extremely fast, etc.
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.
> 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.
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?
> 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.
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.
> 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 :)
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.
It's beautiful and why there's not all that many Emacs users... it requires a commitment, at the very least.
> it requires a commitment
What serious tool doesn't?
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.
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.